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ABSTRACT 


The Computer Aided Prototyping System (CAPS) is used to 
develop executable prototypes of large embedded software 
systems with hard real-time requirements. The system is 
based upon the Prototype System Description Language (PSDL) 
and a set of integrated software development tools. A 
graphical tool is needed to decompose the PSDL composite 
operator into a network which shows its component parts and 
their communication paths. The graphical description is part 
of the specification of the intended system's components. 

This thesis explores the requirements of such an editor 
and demonstrates that it can be developed. It shows that the 
editor can effectively be used to decompose operators and 
that it can produce an equivalent textual representation in 


PSDL. 
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I. INTRODUCTION 


A. RAPID PROTOTYPING 

A need to improve the productivity of software 
development and the reliability of developed programs has 
resulted in research aimed at developing a system which 
allows a designer to rapidly generate prototypes of large 
real-time software systems. This system is based on 
replacing the traditional software life cycle with a two 
phase cycle consisting of rapid prototyping and automatic 
program generation. [Ref. 1] 

The process of designing a large real-time software 
system is long and labor intensive if it is feasible at all. 
Determining whether a system is feasible is often something 
which must be checked and rechecked as the design of a system 
progresses (Ref. 2]. Determining that a very large system is 
unfeasible after the entire system has been developed results 
in a tremendous loss of time and money. A computer-aided 
prototyping system (CAPS) to solve this problem is being 
studied. The rapid prototyping technique provides the 
designer with a means of writing specifications, based on 
user requirements, for components of the system being 
designed and then using reusable software components which 
match the specifications to build a prototype of the intended 
system. This prototype can then be tested to see if the 
design meets the user's needs or whether the user's 
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requirements are even feasible [Ref. 3]. The result is a 
much more timely and cost effective answer to the questions 
of feasibility and whether the design meets the 


specifications. 


B. CAPS OVERVIEW 

The CAPS prototyping environment is comprised of a 
specification language and a set of integrated prototype 
development tools. The Prototype System Description Language 
(PSDL) is used to describe connections between components of 
the system being prototyped and to specify the behavior of 
the reusable components used in constructing the prototype. 
PSDL provides the designer with a means of creating and 
assembling abstractions of the components of the system being 
designed. The prototype development tools in CAPS include a 
user interface with sequence control function, syntax 
directed editor, graphical editor, design database, database 
of reusable software components, rewrite system and an 
execution support system. With these tools and the PSDL 
language the designer can develop an executable prototype of 
the system he is designing. This prototype will not actually 
be the intended system, but rather will be a partial 
representation of the system which can be used to analyze 
various aspects of the design. Since the prototype design is 
based on system requirements, it can be used to demonstrate 
their adequacy. Adjustments to the prototype can be made 
based on customer feedback. It can also be used to validate 
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attributes, timing constraints, I/O formats and module 


interfaces. 


C. GRAPHICAL EDITOR 

In order to construct a prototype of a large real-time 
software system, the designer needs tools which help him 
specify and decompose the system. In the CAPS system, a 
syntax directed editor is used to enter the specifications of 
the components of the system being designed. Based on this 
specification, CAPS tries to find a reusable module which 
matches (or nearly matches) the specification. If the search 
is unsuccessful, a method of decomposing the component is 
needed. The tool discussed in this paper is a graphical 
editor which the designer can use to decompose components of 
the system being designed into their subcomponents. This 
tool provides the user with a visual representation of the 
component decomposition and an equivalent PSDL representation 
which is used by CAPS to aid in the construction of the 
prototype. [Ref. 3] 

Chapter 2 of this paper discusses the CAPS environment in 
terms of the individual tools used for prototype development 
and their functional connection to the graphical editor. 
Chapter 3 provides a detailed description of how the 
graphical editor tool is used for both initial system 
decomposition and for editing an existing prototype. It also 
discusses critical issues involved in the decomposition 
process. The fourth chapter provides a detailed description 
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of the design of the graphical editor. Chapter 5 contains 


the conclusions and discusses possible follow on research. 


II. THE CAPS ENVIRONMENT 


A. THE PROTOTYPING LANGUAGE 
1. PSDL Background 

The high level programming language Ada has several 
features which support the development of reusable modules. 
These features include information hiding, data abstraction, 
and generic packages, among others [Ref. 4]. 

PSDL is a prototyping language designed specifically 
for describing real-time software systems. It supports the 
rapid prototyping concept which is based on abstractions and 
piecing together of reusable components. There is a high 
degree of compatibility between Ada and PSDL, because of 
their similar features and the similar philosophies of large 
system design upon which they are based. In fact, the 
execution. support system of CAPS which produces an Ada 
representation of the design is itself written in Ada. 

A prototype developed using CAPS is an executable 
modularized skeleton of the intended system which is used to 
validate the critical aspects of the system.  PSDL is used to 
describe the behavior of components and their 
interconnections. Its design was motivated by the need for 
several capabilities including: 


1) support of modularized design with explicit module 
interconnection. 


2) an executable prototype. 


3) the ability to decompose large complex systems in a 
simple way. 


4) a common notation for specification and design. 

5) a way to specify reusable module retrieval. 

6) both formal and informal methods of specification so 
that the designer could choose the method most 


appropriate. 


7) support for data abstraction, functional abstraction 
and control abstraction. 


8) a set of built in abstract types for use in 
constructing real-time systems. 


Since no existing language satisfied all of these 
requirements, PSDL was developed. [Ref. 5] 
2. PSDL Constructs 
PSDL is designed to provide the designer with a means 
of creating amodel of a real-time system. With PSDL, the 
designer can hierarchically decompose systems based on data 
flow and control flow. PSDL provides mechanisms for creating 
abstractions for operators, data and control. 
a. PSDL Model 
The mathematical model behind PSDL is an 


augmented graph 
G = (V, E, EVIE C(v)) 


where V is the set of vertices, E is the set of edges, T(v) 
is the maximum execution time associated with each vertex v, 
and C(v) is the set of control constraints associated with 
each vertex v. The vertices represent operators and the 


edges represent data streams. The first three components of 


this model are represented by the data flow diagram which the 
designer develops when he is decomposing an operator with the 
graphical editor. [Ref. 5] 

(1) Operators. Operators are used to represent 
the components of the prototype. They can be used to 
represent functions or state machines. Communication between 
operators is cammed out via data streams. These data 
streams carry values of a fixed abstract data type or values 
of the PSDL built in type EXCEPTION. An operator can be 
either data driven or periodic. Periodic operators fire at 
some interval whereas data driven operators fire in response 
to some stimulus from an input. When an operator fires, two 
things occur. First, it reads one data object from each of 
its input streams. It then writes at most one data object on 
each of its output streams. When a function operator fires, 
output objects are produced whose values depend upon the 
current Bet of input values. State machines produce outputs 
which depend upon the current set of inputs and the current 
values of their internal state variables. Operators can also 
be characterized as being either atomic or composite. If an 
operator cannot be further decomposed into more detailed 
parts, it is atomic. A composite operator can be further 
decomposed into data and control flow networks of lower level 
operators. A composite operator whose decomposition contains 


a cycle is a state machine. [Ref. 5] 


(2) Data Streams. Data streams are the 
communication links between two operators and as such carry a 
sequence of data values. The data streams will be one of two 
types. The first type is called a DATA FLOW STREAM and is 
used to represent a FIFO queue. This type data stream 
guarantees that none of the values it carries will be lost or 
replicated. It also restricts the relative firing rates of 
the two associated operators. Data flow streams are used 
where each data value is unique and must be acted on exactly 
one time. The second type of data stream is called a SAMPLED 
STREAM. This type of data stream makes no guarantees as to 
whether its values will be lost. It is a cell capable of 
carrying just one value which is updated whenever the 
producer operator generates a new value. It can deliver the 
same value more than once if requested and will discard an 
unused value when a new one is generated. Sampled streams 
are used to simulate continuous streams of information where 
only the most recent values are meaningful. Whether a data 
stream represents a data flow stream or sampled stream is 
determined by the consumer  operator's activation conditions. 
[Ref. 5] 

(3) Exceptions. PSDL has a built in abstract 
data type called EXCEPTION. Values of this type are 
transmitted along data streams like values of a normal type. 
The exception type has operations which create named 


exceptions, detect whether the value is a particular named 


exception or detect whether the value is of a type other than 
exception. [Ref. 5] 
b. Abstractions 

PSDL provides the designer with operator, data 
and control abstractions as a means of controlling the 
complexity of his design. 

(1) Operator Abstraction. Operators consist of 
a specification and an implementation. The specification 
contains the form of the interface, timing constraints and a 
formal and informal description of the operator's observable 
behavior. The implementation part determines whether the 
operator is atomic or composite. An atomic operator has a 
keyword ADA, which specifies Ada as the implementation 
language. This is followed by the implementation module for 
the operator which is the result of a successful retrieval of 
a reusable software component, or the writing of the Ada 
component. An operator which can be further decomposed into 
component operators is called a composite operator. Its 
implementation will be a series of PSDL statements which show 
the relationships between its components. [Ref. 5] 

There are two kinds of operator 
abstractions: functional abstraction and state machine 
abstraction. The difference between the two is that a state 
machine abstraction has a state declaration in its 
specification part, whereas a functional abstraction does 


not. [Ref. 5] 


(2) Data Abstraction. Data abstraction is used 
to decouple a data type's behavior from its representation. 
It allows interfaces to be described independent of their 
data representation. Therefore, interfaces in the prototype 
are the same as those in the system being designed. This 
simplifies system validation and enables the structure of the 
prototype to be used in the intended system. [Ref. 5] 

All PSDL data types are immutable, meaning 
that they cannot communicate via side effects. The data 
types include: those Ada built in types which are immutable, 
user defined abstract data types, TIME, EXCEPTION and the 
types which can be built using the PSDL type constructors 


listed in Table 1. [Ref. 5] 


TABLE 1. PSDL TYPE CONSTRUCTORS [Ref. 5] 
set[item: type } 
sequence[item:type ] 
map[from:type,to:type] 
tupteptagel TES tagiene End 
one _of[tag_1:T 1,...,tag n:t n] 


i] 
relation[tag 1:T 1, mtag natin) 


(3) Control Abstraction. Control abstraction in 
PSDL is represented by the enhanced data flow diagrams 
developed with the graphical editor together witha set of 
control constraints. The data flow relationships of the 
enhanced data flow diagram determine the order of execution 


of the operators. [Ref. 5] 
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c. Control Constraints 

An operator's control is specified by its control 
constraints. The aspects of the operator which are specified 
by its control constraints are: whether it is PERIODIC or 
SPORADIC, its triggering condition and its output guards. If 
an output guard is not satisfied it prevents outputs from 
being placed on the output streams. Periodic operators are 
triggered by the static scheduler at some specified interval 
whereas sporadic operators trigger on the arrival of new 
data. 

An operator's triggering condition can be either 
BY ALL or BY SOME. If the triggering condition is BY ALL, 
the operator will fire only when it has new values on all of 
its inputs. This ensures that its output is based on the 
presence of fresh data on all of its inputs. The BY ALL 
triggering condition is used to synchronize processing when 
there are inputs from many data streams. If the BY SOME 
triggering condition is used, the operator will fire when any 
of its inputs get a new value. This guarantees that the 
operator's output is based upon the most recent input values. 
(Ret. 5] 

All operators are required to have a firing 
period or a data trigger and may have both. Periodic 
operators which have data triggers are conditionally executed 


with the data trigger serving as the input guard. 


T 


A timer is Aa abstract state machine used in 
keeping track of time between events, or the amount of time 
spent in a state. It is important that a system for modeling 
real-time systems has a facility for expressing event timing. 
There are four operations which can be performed on timers: 
START, STOP, READ and RESET. These are analogous to the 
operations performed on a stop watch. [Ref. 5] 

Two kinds of conditionals are available in PSDL: 
conditional execution of an operator and conditional 
transmission of output. 

A triggering condition acts as a guard for an 
operator. If an operator's triggering condition is true, it 
reads its inputs and fires. If the triggering condition is 
not true, the operator will read its input data streams but 
will not fire. The triggering conditions for periodic 
operators are tested at an interval specified by its period. 
[Ref. 5] 

An output guard gives the effect of passing an 
unconditional output through a filtering operator. If the 
triggering condition is satisfied, the filtering operator 
fires and passes its input values on. In the event that the 
triggering condition is not met, the filter removes the value 
from its input stream without effecting its output stream. 


[Ref. 5] 
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d. Timing Constraints 

Since timing is a critical issue in real-time 
systems, any language used to specify these systems must have 
provisions for expressing the timing aspects of a system's 
operation. 

There are three basic timing constraints in PSDL: 
MAXIMUM EXECUTION TIME (MET), MAXIMUM RESPONSE TIME (MRT) and 
MINIMUM CALLING PERIOD (MCP). An operator's MET is the 
maximum amount of time it takes to execute from the instant 
it starts to the instant it completes. A sporadic operator's 
MRT is the maximum amount of time between the arrival of new 
data and the time the last value is put into an output stream 
in response to the new input value's arrival. In the case of 
triggered BY ALL, "new data" means the last new input value 
in the ALL list. For triggered BY SOME, "new data" means any 
new input value in the SOME list. The MRT for a periodic 
eee the maximum amount of time from the beginning of 
its firing period to the time when its last value is put onto 
an output stream during that period.[Ref. 5] 

The MCP applies only to sporadic operators. It 
specifies the least amount of time between the arrivals of 
sets of input values. Every sporadic operator with an MRT 
must have an MCP. The MCP must be greater than or equal to 
the MRT for state machine operators in either single or 
multi-processor cases and for function operators in the 


single processor case only. 
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More complex timing constraints can be given by 
using event controlled timers, triggering conditions and 
output conditions.[Ref. 5] 

e. Hierarchical Constraints 

Any PSDL operators which are not atomic must be 
decomposed into their component operators. This 
decomposition is done hierarchically from top down. There 
are several constraints associated with the hierarchical 
structure. Inputs and outputs which occur at one level of 
decomposition must occur at some point in each subsequent 
level of decomposition. Data streams which are introduced by 
decomposing an operator into a network of operators must also 
appear in each further level of decomposition as inputs and 
outputs. METS and MRTs within a decomposition can be no 
longer than those of their associated composite operator. An 
operator's decomposition inherits its period, MCP, and the 
types of its input and output data streams. A composite 
operator inherits the exceptions produced by its component 


operators.[Ref. 5] 


B. PROTOTYPE DEVELOPMENT TOOLS 
The development ofa prototype with CAPS progresses in 
much the same way as a programmer develops a program. The 
primary difference being that with CAPS the user is provided 
with a means of designing at a level of abstraction above 
that of even a high level programming language. Another 
difference is that with CAPS the design is driven directly by 
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the user's specifications which ensure that the end product 
truly will meet the requirements of the intended system. 

A typical programming environment for creating programs 
provides an integrated set of tools which support program 
development and testing. All have a user interface of some 
type (be it friqndly or unfriendly), some form of textual or 
graphical editor for creating and modifying the program, some 
means of storing the program, and a way of testing and 
debugging the program. Program development progresses as a 
cycle of entering a program, repeatedly testing, debugging 
and modifying it until it runs as desired. 

The CAPS prototyping environment has tools which perform 
tasks analogous to those of programming environments. One of 
the primary differences between CAPS and a programming 
environment is that a CAPS prototype is based directly upon 
system requirements. Another difference is that CAPS, unlike 
most ném environments, is heavily dependent upon the 
existence of reusable ADA software components. CAPS has 
tools which support storage of reusable software components, 
formally describing reusable software components, initially 
developing the prototype and support for the test, debug and 
modify phase of development. 

1. System Control 

CAPS is controlled by the sequence control function 
of the user interface subsystem [Ref. 6]. This portion of 


the system provides the user with an easy method of invoking 
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tools, hides the details of tool interaction and prevents the 
user from making system operation errors. 
2. Prototype Creation and Modification 

Two tools are available which support creation and 
modification of the intended prototype. The syntax directed 
editor provides the designer with a means of entering PSDL 
specifications and control constraints for the various system 
components. The graphical editor provides a means of 
decomposing composite operators into networks of component 
operators connected by data streams. When the designer 
signals to the graphical editor that the decomposition is 
complete, the editor scans the operators and data streams and 
creates PSDL link statements [Ref. 7] which are textual 
representations of the graphical objects. 

The syntax directed editor and graphical editor are 
used together in an iterative fashion to enter the 
specifications of the components of the system, specify their 
connections and timing relationships and to ultimately 
decompose the entire system into its atomic parts. Each 
atomic operator will either be implemented by an existing 
reusable Ada module or must be coded. 

As the decomposition process takes place, a prototype 
of the intended system will be assembled in the design 
database. Once the entire specification and decomposition 
process has been completed, the design data base will contain 


an abstract tree representation of the entire system. The 
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central nodes of the tree will contain the information for 
the composite operators and the leaves will be the atomic 
operators. The design database has facilities for retrieval, 
addition and deletion of the PSDL objects that it stores. 

3. Prototype Testing Tools 

The execution support system (ESS) of CAPS is used to 
test the designer's prototype, which is stored in the design 
database, discover errors and make reports to the user so 
that he can make the necessary design modifications. The 
components of the ESS are: a TRANSLATOR, a STATIC SCHEDULER 
and a DYNAMIC SCHEDULER. 

The translator's function is to convert each PSDL 
specification into an executable Ada module [Ref. 8]. The 
static scheduler looks for operators which have timing 
constraints which must be met. It then creates a schedule 
which specifies the order in which the time critical 
aerators must execute. The translated modules and the 
static schedule are passed on to the dynamic scheduler which 
executes the translated modules in the order specified by the 
static schedule. If a time critical module runs in less time 
than was allocated by the static scheduler, the dynamic 
scheduler will schedule non-time critical operators (modules) 
to run during the time gap. The dynamic scheduler also 
provides feedback to the user interface based on run time 


exceptions generated by the translator or static scheduler. 
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4, Reusable Component Support Tools 
The rewrite subsystem of CAPS is used to normalize 
the specification of Ada modules. The reusable software 
component database is used to store reusable Ada components. 
It has facilities for storing, searching for and retrieving 
these reusable components based on their normalized 


specification. 


C. SYSTEM OPERATION 
Development of a prototype using CAPS progresses in two 
distinct phases: 
1) Initial System Design 
2) Test and Modify 
1. Initial System Design 

During this stage of development of the prototype, 
the editors are used to construct an abstract tree 
representation of the prototype. 

Initially, the designer uses the syntax directed 
editor to enter the specification part of the highest level 
operator. The sequence control function then initiates a 
search of the software database for a component which matches 
the normalized description of this specification. This 
search will yield one of three possible results. The first 
possibility, which will become more likely as the software 
database matures, would be that a reusable component is found 
which matches the specification. In this case, the reusable 
component is retrieved and is attached to the specification 
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as the implementation part. The initial design stage would 
be complete at this stage. 

The second possibility would be that a reusable 
module could not be found, but the operator is atomic. 
Atomic operators are those for which no further decomposition 
is necessary. In this case, the implementation part simply 
contains the keyword ADA signifying that the implementation 
must be coded. Again, the design stage would be complete. 

The third and most likely possibility, especially at 
high levels in the design, is that a reusable component will 
not be found and the operator is composite. In this case, 
the graphical editor must be used to decompose the operator 
into a network of operators and data streams at the next 
level of detail. Once the decomposition is complete at this 
level, the graphical editor will transform the graph into 
PSDL link statements. These link statements become part of 
the implementation part of the operator's specification. 
Next, the syntax directed editor is used to enter any control 
constraints which are needed to complete the specification of 
the operator's behavior. Once the entire specification is 
complete, the sequence control function notifies the design 
database of the existence of the new operators so that it can 
allocate their storage. Finally, the PSDL specification file 
for the decomposed operator is stored in the design database 
as an object. The graphical information necessary to 


reconstruct the drawing is also stored with the object. 
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The process described is repeated until the intended 
prototype is completely comprised of atomic operators which 
are either reusable components or modules which must be 
coded. 

2. Test and Modify Phase 

Once the initial prototype design has been completed, 
it is necessary to test it and make necessary modifications. 
Before the testing can occur, the sequence control function 
must collect the specifications together and pass them to the 
ESS [Ref. 6]. 

a. Testing the Design 

Before the prototype design can actually be 
executed, the PSDL specifications must be translated into Ada 
and the order of their execution must be determined. The 
translator scans through the PSDL specification file and 
translates each operator's specification part, implementation 
part and constraint part into an equivalent Ada module [Ref. 
9]. If translation errors are found, translation exceptions 
will be raised, otherwise the translated modules are passed 
to the dynamic scheduler for eventual execution. 

In order to actually execute the Ada modules, a 
schedule is required which will determine the order that the 
time critical modules will execute. The static schedule, in 
simple terms, is a series of calls to the translated modules 
which have time constraints [Ref. 10]. If scheduling errors 


occur then scheduling exceptions are raised. If no 
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scheduling errors occur, the schedule is passed on to the 
dynamic scheduler. 

The dynamic scheduler actually performs the run 
time testing of the prototype. It uses the static schedule 
to call the translated modules. If one of the time critical 
modules does not use up its allocated time slot, the dynamic 
scheduler schedules non-time critical modules to run. If run 
time errors occur, run time exceptions are raised. 
Otherwise, the prototype is feasible and is known to meet the 
specifications. 

b. Modifying the Design 

Exceptions raised during translation, creation of 
the static schedule or during execution signal that the 
prototype design must be modified. The sequence control 
function of the user interface responds by invoking either 
the syntax-directed editor or graphical editor, as 
appropriate, so that the necessary corrections can be made to 


the design. 
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III. USING THE GRAPHICAL EDITOR 


A. PURPOSE 

The graphical editor is one of the designer's primary 
tools for designing the intended system. It provides him 
with a simple way of expressing what the parts of the system 
will be and how those parts interact in terms of time 
relationships and communications. Once the highest level 
operator has been entered, the graphical editor becomes the 
initial point of entry for all lower level operator names, 
data stream names and maximum execution times. 

In order for the graphical editor to provide the designer 
with the maximum expressive power, it must support any type 
of graph which could possibly be used to represent a system's 
components and their associated data streams. It must then 
be able to convert the graphical representation of the graph 
into a textual form which captures the meaning intended by 
the picture. The PSDL link statements are used to express 
what data stream is used to communicate between two 
operators. Figure 1.(a) shows a PSDL specification of an 
operator named SPEED CONTROL SYSTEM. The specification part 
shows that the operator has inputs SHAFT RPM and DESIRED RPM 
and an output ACCEL CONTROL. The two exceptions 
PRESENT SPEED TOO SLOW and DESIRED SPEED TOO SLOW are special 
conditions which will be handled external to the operator 
being decomposed. The maximum execution time shows that the 


22 


SPECIFICATION 
OPERATOR SPEED CONTROL SYSTEM 
SPECIFICATION 
INPUTS SHAFT RPM : real, 
DESIRED MPH : real 
OUTPUTS ACCEL CONTROL: controlling action 
EXCEPTIONS PRESENT SPEED | TOO SLOW, 
DESIRED SPEED ` TOO ` SLOW 
MAXIMUM EXECUTION TIME 2S 
DESCRIPTION 
( Returns command to accelerate, decel- 
erate or hold present setting based on 
a comparison of the present speed with 
the desired speed. If the present speed 
or desired speed are below 30 mph 
exceptions are produced. 


(a) Operator Specification 


SHAFT RFH 
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f GENERATE 


/ 

PESIPED RFM | DESIRED PPH COMPUTE FEM \ AFM DIFFERENTIAL? ^ HTR 

U55777 SPE EDETS APPROPRIATE gia ka A 
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(b) Operator Decomposition 


DESIRED MPH.EXTERNAL--»CONV MPH TO RPM 

DESIRED RPM.CONV MPH TO RPM: 500MS--»COMPUTE RPM DIFF 
SHAFT RPM.EXTERNAL-->COMPUTE RPM DIFF 

RPM DIFF.COMPUTE RPM DIFF:500MS-->GENERATE RESPONSE 
ACCEL CONTROL.GENERATE RESPONSE: 1S-->EXTERNAL 


(c) PSDL Link Statements 





Figure 1 Decomposition of an Operator 
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operator must execute in 2 seconds. Therefore, no path in 
the operator's decomposition can have a total time greater 
than 2 seconds. Figure 1.(b) shows a graph of the operator's 


decomposition. It shows that SPEED CONTROL SYSTEM was 


decomposed into three operators: CONV MPH TO RPM, 
COMPUTE RPM DIFF and GENERATE RESPONSE. Each operator's MET 
is shown above it. DESIRED MPH and SHAFT RPM are shown as 


inputs to CONV MPH TO RPM and COMPUTE RPM DIFF respectively. 
ACCEL CONTROL is shown as an output from GENERATE RESPONSE. 
The lines labeled DESIRED RPM and RPM DIFF are data streams. 
After the decomposition has been completed, the syntax 
directed editor will be used to enter the control constraint 
part of the PSDL specification. This is used to more 
precisely specify the operator's behavior. 

Figure 1.(c) shows the PSDL link statements which the 
graphical editor would produce for the graph shown in Figure 


1.(b). PSDL link statements have the syntactic form 
data stream . source [:MET] --> destination 


where :MET is optional. The maximum execution time must be 


an integer value and have units as shown in Table 2. 


TABLE 2 PSDL TIMING UNITS 


UNITS MEANING 


minutes 
seconds 
milliseconds 
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The source operator name and destination operator name is 
"EXTERNAL" for data streams which come from or go to an 
operator external to the current diagram. 

In order for the designer to be able to alter an existing 
graph in response to errors found during testing, the 
graphical editor must have the capability to reload and 
redraw a previously decomposed operator's diagram. After 
this has been done, the designer can edit the diagram by 


adding and deleting objects from it. 


B. DECOMPOSING AN OPERATOR 
When it has been determined that an operator must be 
decomposed into its components, the user will start the 
graphical editor. In order to reduce the amount of 
information that the designer must memorize, the following 
information must be retrieved from the operator's 
specification part and be made available: 
1) OPERATOR'S NAME 
2) LIST OF INPUTS TO THE OPERATOR 
3) LIST OF OUTPUTS FROM THE OPERATOR 
AJ EIST OP VSTATES 
5) THE OPERATOR'S MAXIMUM EXECUTION TIME 
Making this information available to the designer helps 
to ensure correctness between levels of the graph, because 
once a data stream is identified on one level, it will exist 
on all subsequent levels of that operator's decomposition. 
Once a MET is assigned, each level of the operator's subtree 
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must execute in that same amount time or less. This is where 
the hierarchical constraints of PSDL are realized. 
1. Using the Graphical Editor 

The graphical editor runs in a window environment. 
It has five editing modes which allow the user to draw five 
types of objects: operators, external inputs, external 
outputs, data streams and self loops (PSDL states). The 
default editing mode is DRAW OPERATOR. In this mode the 
designer can draw expandable bubbles with names and time 
constraints (See Figure 2.(a)). The DRAW DATA STREAM mode 
allows lines to be drawn between two previously drawn 
operators (See Figure 2.{b)). Input lines coming from some 
source external to the operator being decomposed can be drawn 
in the DRAW INPUT mode (See Figure 2.(c)). Output lines are 
drawn in the DRAW OUTPUT mode. These lines designate data 
streams which leave the operator being decomposed (See Figure 
2.(d)). The DRAW SELF LOOP mode allows the designer to draw 
state variables (See Figure 2.(e)). Syntax checks are 
done to ensure that the graphical objects are drawn in a 
manner which will ensure that the resulting PSDL link 
statements will be correctly formed. In addition to syntax 
checking the graphical editor also does some semantic 
checking. These checks try to ensure that what the designer 
draws conveys its intended meaning and also that the 
resulting link statements convey the same meaning as the 


diagram. 
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Figure 2 Graphical Objects Used to 
Decompose Operators 
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C. CORRECTNESS AND CONSISTENCY 
1. Syntactic Correctness 

Drawing graphical representations of networks of 
operators is a high level form of visual programming. As 
with any language, this pictorial language has an associated 
syntax. The graphical editor provides a medium for 
constructing these visual programs. It will only accept 
symbols which it knows are in the visual language that it 
understands. User input which fails to fit the syntax of the 
pictorial language is ignored. 

The operator decomposition language consists of 
expandable bubbles and arrows. The bubbles which are used to 
represent operators can be drawn in any size, but must not 
overlap other operators. Allowing bubbles to overlap would 
cause the problem of ambiguous "picking" when connecting or 
deleting operators. 

Arrows represent data streams. Since an arrow can 
have four different meanings in the language, its syntax is 
more complex than operators. Arrows which represent inputs 
to the decomposition diagram, must start ona point in the 
drawing space not occupied by an operator and must terminate 
on an operator. Arrows representing output lines must 
originate on an operator and terminate on a spot in the 
drawing area which is not occupied by an operator. Data 


streams are represented by arrows which start on one operator 
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and terminate on another. PSDL state variables are drawn 
using the self loop mode of the editor. A self loop's arrow 
must start and terminate on the same operator. Lines which 
are not syntactically correct are rejected by the editor and 
immediately erased. 

A correctly formed PSDL operator decomposition 
diagram has all of its component objects named. Therefore, 
the graphical editor will not allow an object to be drawn 
which has not been named. In the case of operators, there 
must also be a MET entered. All names used in the 
decomposition will eventually be used as either module names 
or names of abstract data types (ADT) in the intended 
prototype. Since these modules and ADTs will be implemented 
in Ada, the graphical editor requires that all object names 
are syntactically correct Ada identifiers (See Figure 3). 
The graphical editor also checks that an operator's MET is 


syntactically correct (See Figure 4). 


identifier ::= letter{ (underline |letter or digit} 
letter _or digit ::= letter | digit 


letter :- upper case letters | lower case letters 





Figure 3 Backus-Naur Form of Ada an Identifier [Ref. 11] 


MET ::- «digit string» «time unit» 
Higitostring ::- digit. | digit string 


time unit ::- m | s | ms 





Figure 4 Backus-Naur Form of Maximum Execution Time 
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2. Semantic Correctness 

The same mechanisms used to do syntactic checking of 
a decomposition also provide the semantic checking. The 
editing mode tells the editor what the designer's drawing 
actions should mean. If something is drawn which does not 
fit the syntactic criteria for the object indicated by the 
mode, the system rejects it. This ensures that the 
decomposition will have the designer's intended meaning. 
Without this comparison of editing mode and specific object 
criteria the graphical editor would have no way of ensuring 
that the designer's actions actually conveyed their intended 
result. 

3. View Consistency 

CAPS is faced with a problem common to many software 
development environments which represent objects in multiple 
ways. That is, how to ensure that all other views of an 
entity are appropriately changed when one of them is 
altered.[Ref. 12]. 

A view is a way of representing an object within a 
system. Each decomposed operator has a graphical 
representation which is used to reconstruct the picture and a 
textual PSDL specification representation. After an operator 
is completely decomposed with the graphical editor, the 
editor automatically performs a transformation on the picture 
and produces the equivalent PSDL link statement 


representation. From this point on, the problem of 
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maintaining view consistency exists. A change in one view of 
the object should automatically result in a corresponding 
change to the object's other view [Ref. 12]. Failure to keep 
the PSDL specification view and the graphical view consistent 
will rapidly destroy the integrity and intelligibility of the 
design. Since CAPS does not currently have a method of 
running concurrent view editors, some other method must be 
used to ensure view consistency. 

One way of ensuring view consistency is to make the 
requirement that changes to the specification must be made in 
the graphical editor instead of the syntax-directed editor if 
the change involves any of the following items: 

1) operator names 

2) data flow names 

3) connections between operators 

4) maximum execution times 

5) adding new objects to a decomposition 

6) deleting objects from a decomposition 
For changes involving these items, the existing decomposition 
should be reloaded into the graphical editor, the changes 
should be made as needed and new PSDL link statements and a 
new diagram file should be generated. Then the syntax 
directed editor should be used to make any further changes to 
the operator's specification which are necessary. Changes to 


the specification which do not involve the six listed items 
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could not cause this problem and therefore do not require 
this restriction. 
4. Consistency Between Levels of Decomposition 

After an operator has been decomposed, a new node is 
created in the design database for each new component 
operator. Each input, output and state of the operator being 
decomposed must be represented as an input or output to some 
operator in its decomposition (See Figure 5). 

Ensuring consistency between hierarchical levels 
during the initial decomposition poses very little problem 
because the sequence control function creates a specification 
shell for each new operator in the decomposition [Ref. 6]. 
This shell contains a portion of each new operator's 
specification part (See Figure 6). When the graphical editor 
is used to further decompose each of these operators, the 
sequence control function should pass in the operator's name, 
its input list, output list, state list and MET. Making 
these items available will help the designer ensure that each 
input, output and state of the operator being decomposed is 
used in the decomposition. In addition, the availability of 
the MET will reduce the likelihood of a time constraint 
violation in his decomposition. 

Maintaining consistency between levels when making 
modifications is more difficult for certain types of changes. 
If an operator in any particular level is deleted, his entire 


subtree must be deleted from the design database. This is a 
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Figure 5 Decomposition of Operator into 
Its Component Operators 
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simple process. However, if an operator's connectivity is 
changed by deletion, addition or by redirecting of data 
streams, its entire subtree must be rechecked to ensure 
consistency. This should be done in the same top down 
fashion as decomposition, having the sequence control 
function pass in the input, output and state names for the 
appropriate operator as is done with decomposition. Also of 
value in this process is the ability to look up or down a 
level in the decomposition hierarchy. However, allowing the 
designer to randomly edit up and down between levels could 
cause inconsistencies between the pictorial view and the 
specification. The problem being that as the diagrams are 
changed, the specifications would remain unchanged. With a 
sufficient number of changes, it could become very difficult 


for the designer to make the textual and pictorial views 


match. 
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IV. DESIGN OF THE GRAPHICAL EDITOR 


A.  STATIC SCHEDULER CONSIDERATION 

The static scheduler is the portion of CAPS which uses 
the decomposition information contained in the PSDL link 
statements. Therefore, it has a major impact on the design 
of the graphical editor. 

The static scheduler determines precedence relationships 
between operators by analyzing the link statements. Research 
was conducted with the intent of reducing the amount of time 
and memory required to perform the scheduling task. One 
possible solution, which was investigated, was to supply the 
scheduler with the exact source and destination of the inputs 
and outputs of the decomposition. Doing this would require 
the static scheduler to only consider the link statements of 
the composite operators which are parents of atomic 
operators. For a large system this would be a large 
reduction in the quantity of operators considered. 

This approach was determined to be unfeasible for two 
reasons. First, there were situations where a single data 
stream in a decomposition could be represented by two 
equivalent link statements that the machine could not 
determine were equivalent. Figures 7 through 10 show a 
decomposition which illustrates this problem. The circled 
pairs of link statements in Figures 7 and 8 represent the 
same connections, but due to their different names the 
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Figure 7 Overall System Decomposed into its Component 
Operators 
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inputl.external-->A a 
ds abl.A a:ls-->A b 


ds ab2.A a:ls-->A b 
ds acl.A a:1s-->A c 
ds ac2.A a:1s-->A c 
ds cb.A c:1s-->A b 


ds a.A b:Is-->Proc b 












ds b.A b:Is--»Proc b 


ds e.A c:Is--»Proc c 


Figure 8 Decomposition of Proc a 
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input2.external-->B a 


ds a.Proc a:25-->B a 


ds b.Proc a:25-->B b 
ds Babl.B a:500ms-->B b 


ds Bab2.B a:500ms-->B b 


ds c.B b:500ms-->Proc c 


ds d.B b:500ms--»Proc c 


Figure 9  Decomposition of Proc b 
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ds e.A c b:500ms-->Proc c 


Figure 10 Decomposition of A_c 
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machine could not possibly discover this. Second, sorting 
through all of the link statements associated with all of the 
atomic operators creates a potentially unsolvable problem. 

A tree data structure can be used to assist in the 
creation of a schedule of operators. Store the name of the 
highest level operator in the root of the tree. Then 
determine the schedule for the operators in the root 
operator's decomposition. Store the names of these operators 
as children of the root operator in the order that they must 
be scheduled. Repeat this process for all operators until a 
tree containing all of the system's operators has been 
created. When the tree has been completely built, its 
frontier will contain a linear schedule of the operators (See 
Figure 11). Since this method does not require that one 
subtree have any knowledge of connections to other subtrees, 
there is no need for explicit sources and destinations for 
external inputs and outputs. The linked storage structure 
which is assembled by the graphical editor during a given 
operator's decomposition need only provide the information 
for showing relationships between the components of that 
operator's decomposition. 

Based on these discoveries, the graphical editor was 
designed so that inputs and outputs for any decomposition 


come from and go to operators named EXTERNAL. 
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Figure 11 Storage of Operator Names in Tree Structure 
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B. INTERFACE DESIGN INFLUENCES 
Four factors influenced the design of the graphical 
editor's user interface: 
1) the choice of machines on which to implement CAPS 
2) the choice of interface software support 
3) human factors issues 
4) user interface design guidelines 
1. Sun Workstation 
The Sun Workstation has many features which make it 
the machine of choice for the development and implementation 
of CAPS. The availability of a dedicated CPU in a 
multitasking environment greatly enhances the design team's 
ability to code, test and debug their software. The Sun 
Workstation provides a powerful integrated programming 
environment based on the unix operating system with its 
standard utilities which include: 
1) Ada, C, Pascal and Fortran 77 compilers 
2) vi and emacs editors 
3) dbx debugger 
4) make 
5) revision control systems 
and numerous others [Ref. 13]. 
2. Interface Software Support 
a. Sun View 
Sun View is a window based user environment which 


supports interactive graphics-based applications. There are 
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two aspects to Sun View. First, it is a user interface which 
provides multiple overlapping windows, each of which can run 
a task independent of the other windows. Second, it is a 
general toolkit for building window-based applications. A 
set of subroutine libraries provide three levels of 
abstraction for development of program interfaces [Ref. 14]. 

The highest level of abstraction for interface 
design is provided by the SUNTOOL library. It provides the 
functions of the User Interface Management System (UIMS) and 
also the functions necessary for the interactive creation of 
window applications. [Ref. 15] 

The SUNWINDOWS library provides the middle level 
of interface abstraction. These functions are used to manage 
the hierarchy of overlapping windows. [Ref. 15] 

The lowest level of abstraction is provided by 
the PIXRECT library. This library provides the functions 
needed for low level manipulation of pixels. [Ref. 15] 

b. Interface Utilities 

Sun View provides built in user interface 
utilities. The NOTIFIER is used to capture and distribute 
events among the multiple applications which are running. A 
SELECTION SERVICE is used to manage text selections. [Ref. 
14] 

c. Interface Building Blocks 
Four types of windows are provided as building 


blocks for constructing user interfaces [Ref. 14]: 
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1) canvases provide an area on which programs can draw 
2) text subwindows are used to display textual data 
3) panels contain buttons and choice items 


4) tty subwindows provide a capability to run other 
programs 


d. The Sun View Model 

Sun View is an object-oriented system whose 
objects are assembled in such a manner as to build a user 
interface. There are six classes of objects, the most 
important of which is a window (See Figure 12). Within the 
window class are the objects subwindow and frame. The 
subwindow objects are Canvas, Panel, Text and TTY. 

Frames are window objects which themselves can be 
overlapped. They serve as a frame which surrounds a group of 
nonoverlapping subwindows, allowing them to be operated on as 
a unit. 

Frames may also contain other frames. So the 
overall structure of Sun View is a tree of windows. The root 
of the tree is the base frame. The non-leaf nodes are frames 
and the leaf nodes are subwindows [Ref. 14]. Figure 13 shows 
the tree structure of the objects which comprise the 
graphical editor. 

3. Human Factors 
Since the graphical editor is a tool designed to aid 
a human in development of a software system prototype, human 


factors must be considered in its design. 
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Figure 12 Sunview Objects [Ref. 14] 
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Figure 13 Tree Structure of Objects Comprising 
the Graphical Editor 
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a. Functional Principle 
Systems with many controls can be very difficult 

to learn and use. To reduce this difficulty and also reduce 
the likelihood of errors, controls should be grouped 
according to their functionality  [Ref. 16]. The graphical 
editor's controls fall into three functional groups (See 
Figure 14): 

1) system control group 

2) editing mode group 

3) text input group 

b. Sequence of Use Principle 
Another way to improve the usability of a group 

of controls is to organize them in the same sequence that 
they are used. This improves the usability of a system by 
eliminating the need to jump around and therefore minimizing 
the amount of information the user must remember [Ref. 16]. 
The controls of the graphical editor are organized to be used 
in a series of top to bottom sequences. The top panel is 
used to control overall system functions: LOADING, STORING 
AND QUITTING. This panel is only used at the beginning and 
end of an editing session. The next panel down is the 
editing mode panel. It is used to switch from drawing one 
type of object to another. After the editing mode is 
changed, the user must enter a name and in the case of an 
operator, a time constraint. The input panels for these are 


therefore located immediately below the editing mode panel. 
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Figure 14 
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The drawing canvas is located immediately below the input 
panels. This ordering of controls always allows, but does 
not force, the user to operate ina top to bottom circular 
fashion as follows: 

1) select mode (optional) 
2) enter and read name 
3) enter and read time constraint (if in operator mode) 
4) draw object 
5) repeat until done 
c. Human Memory Capacity 
Studies have shown that humans have the capacity 
to remember 7 + 2 things [Ref. 16]. With this in mind, 
interface designers should keep the length of selection lists 
within this boundary if possible. The graphical editor was 
designed to meet this criteria. It consists of five basic 
parts and its longest menu has only five choices. 
4. User Interface Design Guidelines 
Reference 15 provides a list of guidelines which 
should be applied when designing a user interface. 
1) Be intuitive (things should work as you would expect) 


2) Accommodate experts and novices (provide confirmation 
override mechanisms) 


3) Allow customization 
4) Provide extensibility 


5) Use lots of feedback (show status; make error messages 
clear) 


6) Be predictable (use a consistent, easy to remember set 
of basic actions in obvious ways) 
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7) Be deterministic (consider type ahead and mouse ahead 
effects) 


8) Avoid modes (if states that persist are necessary, 
make the feedback and exit path obvious) 


9) Do not preempt the user (don't force them to respond) 


C. INPUTS AND OUTPUTS 
1. Inputs 

The graphical editor accepts inputs from either the 
mouse or the keyboard. No restrictions are placed on the 
order that any of these inputs must occur except that a name 
must have been read before any type of object can be drawn. 
In the case of an operator a MET must also have been read. 
Figure 15 shows a black box representation of the graphical 
editor with all of its inputs and outputs. 

An operating mode select event occurs when the mouse 
pointer is placed over one of the operating mode buttons and 
the left mouse button is pushed. This type of input selects 
whether the editor should (1) load an existing diagram, (2) 
store the current diagram or (3) quit. The default mode is 
for the editor to be ready to create a new diagram. 

An editing mode select event is also a mouse input. 
This input establishes the context in which canvas events 
will be interpreted. 

To draw an object the user positions the mouse 
pointer in the canvas area, pushes the left mouse button 
down, moves idt to another location and releases it. 
Releasing the left mouse button causes an end of object event 
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Figure 15 Inputs and Outputs of the 


Graphical Editor 


S 


which tells the editor to draw the object using the start and 
stop locations. 

To delete an object the user positions the mouse on 
the object to be deleted and initiates a right mouse button 
down event. This input will erase the object from the 
display and free up its storage. 

Textual inputs to the graphical editor are typed in 
via the keyboard. These inputs will only be accepted if the 
mouse pointer is located in one of the text panels. After 
text input has been entered, it must be validated by causing 
a read event. This is done by positioning the mouse pointer 
over the appropriate read button and pushing the left mouse 
down. 

If the graphical editor is going to be used to edit 
an existing diagram, the user interface function must 
retrieve the necessary reconstruction information from the 
design e and store the information in a file named 
graph.pic prior to invoking the editor [Ref. 6]. The 
graphical editor then reads in this information and 
reconstructs the diagram. 

2. Outputs 

The graphical editor has two kinds of outputs: 
visual and textual. If the user draws an object, it is 
displayed on the canvas so that he can see it. If a user 


generated error occurs, an error message will immediately be 
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displayed at the top of the canvas. Once the error condition 


has been corrected, the error message disappears. 


When the mouse is in a particular subwindow of the 
display, visual feedback in the form of a bold subwindow 
border, is provided. 

After a decomposition has been completed and the user 
has selected store, the editor will generate two kinds of 
textual output. The PSDL link statements will be written to 
the file graph.link. Also, the information needed to 
reconstruct the diagram will be written to the file 
graph.pic. The user interface will store this information in 


the design database [Ref. 6]. 


D. DATA STRUCTURES 

The primary storage structure for the graphical editor is 
a linked list of operators. A single structure named 
Operator list has pointers to the head and tail elements of 
this list. Each element in the operator list is a structure 
of type Operator. The Operator structure has ten fields (See 
Figure 16). 

The name field is a pointer to a name structure which is 
comprised of an 40 character array and a field specifying the 
length of the name. The optype field is used to signify 
whether the structure represents an actual operator or 
whether it represents a NULL operator which is used as the 
source for external inputs. The xstart and ystart fields 
specify the starting (x,y) coordinates of the operator. The 
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Figure 16 Operator Storage Structure 
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xstop and ystop fields contain the operator's stopping (x,y) 
coordinates. The met field contains a pointer to a Met 
structure which is identical to a Name structure. The last 
three fields are pointers. The head and tail fields point to 
a linked list of lines which leave this operator. The next 
field points to the next operator in the linked list of 
operators. 

As mentioned in the previous paragraph, each operator has 
an associated line list. This line list is a linked list of 
structures of type Line (See Figure 17). These lines 
originate at the operator to which they are attached. 

The name, xstart, ystart, xstop, ystop and next fields of 
the Line structure serve the same purpose as they did in the 
Operator structure. The Intype field is used to identify 
whether the line is an input, output, data stream or a state. 
The dest field is used to point to a name structure which 
holds the name of the operator on which the line terminates. 
For output lines, this field will always point to a name 
structure containing the name EXTERNAL. Figure 18 shows a 
decomposition of an operator. Figure 19 shows the resulting 


storage structure generated during the decomposition process. 


E. ALGORITHM FOR THE GRAPHICAL EDITOR 
At a very high level, the algorithm for the graphical 
editor is simply: 
1) create the window 
2) poll for events 
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Figure 17 Line Storage Structure 
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Sun View has built in routines which allow the interface 
designer to construct an interactive window application. The 
interface designer need only provide the routines for 
handling the details of the application. The Appendix 
contains a program listing of the graphical editor. 

1. Create the User Interface 

The user interface for the graphical editor is a 
window comprised of five subwindows, each of which is one of 
the Sun View application building blocks. 

The first step in creating a Sun View application is 
to create a frame. This is done with the Sun Window routine 
window_create. Parameters for this routine allow the 
specification of various attributes for the frame object. 
These attributes include its name, icon, size, location, 
window type, location on the screen and numerous others. 

After the frame has been created, the routine 
window_create is used to create each of the subwindows which 
are used to fill in the frame. The graphical editor frame is 
tiled in with four panel subwindows and a drawing canvas 
subwindow. 

2. Poll for Events 

In conventional interactive programming the main 
event polling loop resides within the application program. A 
notification-based system such as Sun View has the polling 
loop in ae notifier. The notifier reads events and then 


notifies the appropriate application procedure that input has 


60 


occurred. This scheme requires that each procedure must be 
registered with the notifier so that it knows who to call for 
a particular event. The advantage to this is that the system 
takes over the job of managing the event-driven environment. 
[Ref. 14] 

The Sun Window routine panel create item is used to 
build a panel subwindow. The parameters for this procedure 
include its name, image type, image label and the procedure 
to be notified when the button is pushed. So procedures 
which are to be called as a result of a button being pushed 
are registered with the notifier by the panel create item 
routine. 

a. System Control Events for the Graphical Editor 

The user of the graphical editor must have a 
means of retrieving previously generated diagrams and storing 
new or altered diagrams. He must also have some way to 
terminate the editor. These capabilities are provided by the 
following buttons which are located in the top subwindow of 
the graphical editor frame: 

1) load existing 

2) store 

3) quit 
When the graphical editor is started it comes up in a mode 
which allows the user to create a new decomposition diagram. 

(1) Load Existing. The graphical editor can 


also be started for the purpose of editing a previously drawn 
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decomposition. To load the diagram the user must click on 
the load_existing button. This will cause the routine 
load_proc to read the file graph.pic which contains the 
reconstruction data. This data must have been previously 
retrieved from the design database by the user interface 
[Ref. 6]. When the load proc routine reads in the 
information for the graphical object, it checks to see if the 
object is an operator. If it is an operator, an operator 
storage element is created, filled in with its information, 
and is attached to the list of operators. If the object is 
of type EXTERNAL, an operator element is also created and is 
linked to the operator list. EXTERNALS are NULL operator 
nodes which serve as the source operator for input lines. The 
only fields of an EXTERNAL which get useful values are those 
pointing at the line list. 

Any object encountered during the load 
process which is not an operator or external is some type of 
line. Therefore, a line storage element is created, its 
values are filled in and it is linked to the line list of the 
last operator which was read in. 

After all of the objects in the file being 
loaded have been read in, stored and linked, the diagram is 
ready to be drawn. Load proc's final action is to call the 
routine redraw diagram which traverses the entire linked 


storage structure and draws each object. 
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(2) Store. After the user has completed drawing 
or altering a decomposition diagram, two things must be done. 
First, the information in the diagram must be stored in a 
manner which allows it to be redrawn. Second, the diagram 
must be converted into the equivalent PSDL link statements. 
These link statements will be attached to the implementation 
part of the PSDL specification file by the sequence control 
function [Ref. 6]. 

Information for diagram reconstruction is 
scored by the routine store diagram. This routine does a 
traversal of the storage structure, writing out the contents 
of each operator node immediately followed by the contents of 
each of its associated line nodes. 

Creating the PSDL link statements is a 
similar process. The create PSDL routine traverses the 
entire storage structure, generating a PSDL link statement 
for each line node it finds. The link statement is a string 
of characters which result from the concatenation of the 
following six substrings: 

1) the line name (stored in the line node) 
2) the character "." 


3) the source operator's name (the name of the operator 
whose lines are being processed) 


4) an optional ":" and MET (if the source operator has an 
MET) 


5) the character string"--»" 


6) the destination operator's name (stored in one of the 
line nodes fields) 
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After the diagram has been stored, the 
store diagram routine tells the system that it is safe to 
exit. 

(3) Quit. The user may terminate the editor by 
clicking on the quit button. This action will cause the 
routine quit_proc to execute. This routine will first check 
to see if the diagram has been stored. If so, it will destroy 
the window. If the diagram has not been saved, an error 
message will appear on the drawing canvas telling the user to 
store the diagram. The user can terminate the session 
without saving by positioning his mouse pointer on the black 
bar at the top of the window and pushing his right mouse. A 
pop-up menu will appear which has quit as one of the choices. 


Selecting this will circumvent the storage check and kill the 


editor. 
b. Mode Select Events 
The graphical editor always starts in the DRAW 
OPERATOR mode. This is because operators must be drawn 


before data streams. This requirement has the advantage of 
making it easy to check the syntax of the diagram. The 
editor ensures that lines intersect operators in the way 


which is appropriate to their type (i.e. input, output, 


etch- 

To switch operating modes, the user clicks on the 
desired mode. The selector will switch to reverse video 
indicating that it has been selected. The selection causes 
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the notifier to call the mode select routine which sets the 
global edit mode variable to the appropriate value. This 
establishes the context in which canvas events for the left 
mouse button will be interpreted. 

C. Text Panel Events 

The graphical editor has two panels which provide 
a means of entering textual information. 

(1) Name Panel. The name panel allows the user 
to enter a name for an operator or a line. After the name 
has been typed in, the read name button must be selected. 
This action causes the notifier to inform the routine 
input_name to read the panel and also causes the routine 
is valid ada id to check the syntax of the name. If the name 
is not a valid Ada identifier, an error message is displayed 
and the system rejects drawing events on the canvas. 

(2) MET Panel. The MET panel works essentially 
the same as the name panel. The only difference is that the 
routine is valid MET is used to check that the value is an 
integer and that it has the proper units. Invalid values 
result in an error message and a lockout of operator events 
from the canvas since only operators have an MET. 

d. Canvas Events 

The graphical editor screens the event handler 

for left mouse down events, left mouse drag events, left 


mouse up events and right mouse down events. 
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(1) Left Mouse Down. If the 
process canvas events routine receives a left mouse down 
event it will capture the x and y coordinates of the position 
where the event occurred. These values are stored and become 
the starting position of the object being drawn. Which 
object is drawn depends upon the current editing mode. 

(2) Left Mouse Drag Events. If the left mouse 
is down and drag events are detected, the 
process canvas events routine will rubberband the object. As 
the mouse pointer is moved across the Screen 
process canvas events repeatedly captures the position of the 
pointer. For each new position, the routine rubberband is 
called to blank out the previous version of the object and 
then redraw it using the most recent starting and stopping 
coordinates. The result is that the line is erased and 
redrawn as fast as the user moves the pointer across the 
screen. 

(3) Left Mouse Up Events. When a left mouse up 
event occurs, the process canvas events routine calls 
rubberband a last time to delete the last rubberbanded 
version then captures the final stopping coordinate. The 
routine process object then performs the syntactic and 
semantic checks on the object. 

(a) Processing Operators. If the editing 
mode is DRAW OPERATOR, process_object will verify that a name 


and a MET are available and that the coordinates of the new 
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operator do not overlap another operator. When all of these 
conditions are satisfactory it calls the routine 
process_operator. This routine will cause the following 
seven steps to take place: 

1) the object will be drawn 

2) the MET will be retrieved 

3) the name will be retrieved 

4) the name will be displayed, centered in the operator 

5) the MET will be displayed, centered over the operator 

6) the operator will be allocated storage and stored 


7) the stored operator will be appended to the list of 
operators 


(b) Processing Lines. If the editing mode 
is DRAW DATA STREAM, DRAW INPUT, DRAW OUTPUT or DRAW SELF 
LOOP, routine process_object will verify availability of a 
legal Ada identifier and will ensure the line intersects an 
operator in the appropriate fashion. If the checks turn out 
satisfactory, the routine process line is called. This 
routine will cause the following actions: 

1) draw the appropriate line 

2) draw the arrowhead on the end of the line 

3) if the Line is an input line: 
a. creates a NULL operator to act as its source 
b. links the NULL operator to the operator list 

4) retrieves the line's name 

5) displays the name on the line 

6) creates the storage for the line and fills in the 


values 
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7) appends the line to the source operator's list of 
lines 


(4) Right Mouse Down Events. When a right mouse 
down event occurs, the routine process canvas events checks 
to see if the mouse's coordinates are within the pick 
criteria of either a line or an operator. If so, the object 
is deleted from the storage structure by routine delete line 
or delete op as appropriate. After the deletion is complete, 


routine redraw_diagram draws the remaining objects. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

This thesis shows that a graphical editor for performing 
hierarchical decomposition of composite PSDL operators can be 
designed and implemented. It also demonstrates that a linked 
list of operators each containing a linked list of outputs is 
an effective method of storing the graphical elements. This 
is evidenced by the speed which diagrams can be loaded, 
stored, redrawn and deleted from. This method of storage is 
also shown to support the transformation of a pictorial 
diagram into textual PSDL link statements. 

It also shows that through the use of modes, the 
graphical editor can perform syntactic and semantic checks 
during the decomposition. These checks ensure that the PSDL 
link statements are always of the proper form and convey the 
designer's intended meaning. 

Research on the graphical editor, as it relates to PSDL, 
indicates that the prototype design will take shape in the 
editor. Therefore, there is a need to start new 
specification files for each new operator introduced during a 
decomposition. Each of these new files will contain the 
operator's name, inputs, outputs, states and MET. 

This research indicates that using the graphical editor 
to randomly edit up and down through the objects in the 
design database has the potential to cause inconsistencies 
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between the specification of an operator and its plctorial 
values. A better method would be to make corrections ina 
top-down fashion, alternating between graphical editor and 
the syntax directed editor for each object. This method, 
although slower, would ensure view consistency between the 


textual and graphical representations of the decomposition. 


B. RECOMMENDATIONS 


1) The requirement that forces the user to enter the 
textual values for an object before it is drawn 
decreases the user friendliness of the graphical 
editor. A method should be developed which allows 
entry of this textual information at any time during 
the decomposition process. 


2) Work should be done to make the system configurable. A 
user should be able to disable checking and therefore 
enter any object in any order desired. This would 
greatly improve its appeal to the expert user. 


3) The process of decomposing an operator is like 
programming with objects. A better way to enter an 
operator's specification might be to open a window 
within the graphical editor which allows the user to 
define the object as it is being created instead of 
using a syntax directed editor to enter its 
specification. 


4) Currently the graphical editor only supports prototypes 
written in Ada. Providing a panel with a choice of 
languages, which would enable an appropriate identifier 
syntax checker, would make the editor less language 
specific. 


5) Currently all error messages are displayed on the 
drawing canvas. A better method would be to display 
them in dialogue boxes. 


6) The user should be able to just "pick" the names of all 
external data streams from a list of inputs and 
outputs, that are passed to the editor when it is 
invoked, rather than being required to type them. This 
would eliminate another possible source of errors. 
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APPENDIX 
PROGRAM TEXT FOR THE GRAPHICAL EDITOR 


«stdio.h» 
<suntool/sunview.h> 
<suntool/canvas.h> 
<suntool/panel.h> 
<suntool/seln.h> 
«math.h» 
<string.h> 
<ctype.h> 


/* define constants for the object types 
OPERATOR 0 
DATA_STREAM 1 
SELF_LOOP 2 
INPUT 3 
OUTPUT 4 
EXTERNAL 5 


PI 3.141592654 VES Crue tee tege pr 


DISP WIDTH 140 /* display width 
DISP HT 50 /* display height 


ARROW LENGTH 9 /* length of the arrow head 
TEXT MAX LEN 35 /* length of name which is visible 
TIME MAX LEN 10 /* length of the met which is visible 
PROXIMITY 25 /* define size of line pick region 

/* import predefined editor icon 


hort editor icon[] = { 
"/usr/suns2/thorsten/graphics/editor.icon" 


CON FROM IMAGE(editor, editor icon); 


frame; /* handle for frame 
op mode panel, /* handle for top panel 
edit mode panel, /* handle for side panel 
met panel, /* handle for met panel 
name panel; /* handle for name panel 
drawing canvas; /* handle for drawing canvas 
*event /* handle for events 
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xy 


Pixfont 


Pixwin 


BS 


ime 


int 


*bold; 
*drawing pw; 
edit mode; 


name checked - 0, 
met checked 0; 


graph saved OF 


Panel item object name, 


char 


FILE 


time constraint; 


*name buf, 
*met buf; 


Efe 
Be /* 


typedef struct 


{ 


int length; 
char string[40]; 
}Name, Met; 


typedef struct line 


{ 
Name 
int 
int 
INE 
INE 
Int 
Name 


*name; 
lntype; 
xstart; 
ystart; 
XStOp; 
ystop; 
*dest; 


struct line  *next; 


)Line; 


typedef struct operator 


{ 
Name 
int 
int 
int 
int 
int 
Met 
Line 
Line 


*name; 


/* handle for borders 


/* handle for drawing pixwin 


/* global - stores the current edit mode 


/* global - signals that name is valid 
/* global - signals that met is valid 


/* global 


— signals saved status 


/* handle for name 
/* handle for met 


/* global - buffer to read the name into 
/* global - buffer to read the met into 


/* PSDL link statement file 
file which holds the reconstruction info 


/* storage struct for names and mets 


/* array to hold 


/* 


/* identifies 
/* x coord 
"LE EC Oo 
/* x coord 
/* y coord 


/* string length 
the name or met string 


line storage structure 


/* name of line 
the type of line it is 
of line starting posit 
of line starting posit 
of line stopping posit 
of line stopping posit 


/* operator on which line terminates 


/* pointer to 


next line in this list 


/* operator storage stucture 


/* operator's name 


optype; /* identifies contents as operator or external 
where operator should start to be drawn 
where operator should start to be drawn 
coord of the operator's opposite corner 
coord of the operator's opposite corner 
maximum execution time for the operator 

/* head of the operator’s output list 

/* tail of the operator’s output list 


xstart;  /* x coord 
ystart;  /* y coord 


xstop; /* x 
ystop; /* y 
*met; Z 
*head; 
*tail; 
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struct operator *next; /* pointer to next operator in list */ 
JOperator; 


typedef struct /* the list for operators */ 
{ 
Operator *head; /* pointer to the head of the list */ 
Operator *tail; /* pointer to the tail of the list */ 


JOperator list; 


Operator list operator list; 
Operator list *op list - &operator list; 


Operator HcpDNEUSOD NEGO 
Name name pointer; 
Name *name — &name pointer; 
Met Bec 
Line *ln; 
/* forward declarations of functions */ 
static Notify value process canvas events(); 
static Notify value mode select(); 


Operator *alloc operator(); 
Operator *pick_operator(); 
Operator *create op(); 


Line *alloc line(); 

Line *pick line(); 

Line create line (); 
Name *external(); 

Name *get name(); 

Met *get met(); 

int iscopSpick (0). 

int is line pick(); 
int is valid ada id(); 
int is valid met(); 


/* forward declarations of procedures */ 

help proc(); 

quit proc(); 

load proc(); 

store proc(); 

input name (): 

input met(); 

append line to op(); 
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is op pick(); 

is 3nput-cpyekx0 
process operator(); 
process line(); 
rubber band(); 
redraw diagram(); 
delete line(); 
delete op(); 

delete input lines(); 
display error msg(); 
display name(); 
display met (); 

draw arrowhead(); 
draw object(); 
create PSDL(); 

store diagram(); 
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main(argc, argv) 
KS o oko o o k kk eo oo oo o o 5 XX X 3 k. 3 x 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: create operating mode panel() 
create editing mode panel() 
create name panel() 
create met panel() 
process canvas events () 


CALLED BY: N/A 


PURPOSE: creates the frame and the subwindows which comprise the 
graphical editor. It also registers the routine 
process canvas events with the notifier. 


x É k K k k k k Kk k K k k KK I IK KIKI IK I KR c kk Ok kk kk Ck Ck Ok kc OK Ck Ck Kk Kok xk kckckck kc k ck ck ck ck kckckcok kc k k X / 


Sir argc; 
char **argv; 


/* cause borders to highlight if region entered */ 
bold - pfoopen(t"/usr/lib/fONEs/fixedwidthfonts/screen.b.12"); 
if (bold -- NULL) exit(1); 


/* create the outer display frame */ 
frame = window create (NULL, FRAME, 


FRAME LABEL, "graphical editor", 
FRAME ICON, &editor, 

FRAME CMDLINE HELP PROC, help proc, 

FRAME ARGS, argc, argv, 

WIN ERROR MSG, "can't create window.", 
WIN X, 15, 

WIN Y, er 

WIN ROWS, DISPSHT, 

WIN COLUMNS, DISP WIDTH, 

0); 


/* create op mode panel */ 
op mode panel - window create(frame, PANEL, WIN FONT , bold, 0); 
create operating mode panel(); 


/* create editing mode panel */ 
edit mode panel - window create(frame, PANEL, WIN FONT, bold, 0); 


create editing mode panel(); 


/* create panel to read object names */ 
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) 


name_panel = window_create(frame, PANEL, WIN_FONT, bold, 0); 
create name panel(); 


/* create panel to read operator's met 
met panel = window create(frame, PANEL, WIN FONT, bold, 0); 
create met panel(); 


/* create canvas to draw on 
drawing canvas - window create(frame, CANVAS, WIN FONT, bold, 
WIN CONSUME KBD EVENT, WIN ASCII EVENTS, 
WIN EVENT PROC, process canvas events, 
CANVAS RETAINED, TRUE, ODE: 


/* cause drag events to be accepted 
window set(drawing canvas,WIN CONSUME PICK EVENT, LOC DRAG, 0); 


/* define drawing pixwin 
drawing pw — canvas pixwin(drawing canvas); 


/* initialize the operator list 
operator list.head = operator list.tail = NULL; 


/* poll for events in the frame 
window main loop(frame); 


/* end main */ 
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create operating mode panel() 
kk 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: load proc() 
store proc() 
quit proc() 


CALLED BY: main() 


PURPOSE: This routine builds the top panel of the display which 
contains the operating mode buttons. It also registers 
the routines load proc, Store proc, and quit proc with 
the notifier. 


* k k * K k k K k k K k * k k k K k k k k k k k k k K k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k / 


{ 


} 


/* display panel message 
panel create item(op mode panel, PANEL MESSAGE, 
PANEL LABEL STRING, 


(left mouse selects) B ME 


/* create button to load reconstruction info 
panel create item(op mode panel, PANEL BUTTON, 
PANEL LABEL IMAGE, panel button image (op mode panel, 
"Load Existing", 0, 0), 
PANEL NOTIFY PROC, load proc, 0); 


/* create button to store the diagram 
panel create item(op mode panel, PANEL BUTTON, 
PANEL LABEL IMAGE, panel button image(op mode panel, 
"Store", 0, 0), PANEL NOTIFY PROC, store proc, 0); 


/* create button to terminate the program 
panel create item(op mode panel, PANEL BUTTON, 
PANEL LABEL IMAGE, panel button image(op mode panel, 
Hoye (We ir 
PANEL NOTIFY PROC, quit proc, 0); 


/* fit border around the top panel 
window fit height(op mode panel); 


/* end create operating mode panel */ 


79 


*/ 


s 


a 


a 


s 


create editing mode panel() 
[RR TR RRR AER KOK KOK A Z k K k KOK K k K KK X A 2 XX A K KOK X Kk oio olg DR E K XA A K RGM Er] Hk XG A ESE eee 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: mode select () 

CALLED BY: main() 


PURPOSE: This routine builds the edit mode panel and registers the 
routine mode select with the notifier. 


kk kk K k k k K k * K k k k k k k k k k k k K k k k k k K K kk K kk k k k k k k k k k k k k k k k k k k k k k k kk k k k kk k k k k k / 
{ 
/* put blank line in panel */ 
panel create item(edit mode panel, PANEL MESSAGE, 
PANEL LABEL STRING, 


0); 


/* create the mode select panel */ 
panel create item(edit mode panel, PANEL CHOICE, 


PANEL LABEL STRING, Editing Mode: T 

PANEL CHOICE STRINGS, " Draw Operator n 
" Draw Data Stream U 
u Draw Self Loop v 
T Draw Input E 
» Draw Output ur 
0, 

PANEL FEEDBACK, PANEL INVERTED, 

PANEL NOTIFY PROC, modenselcot o) 


/* insert a blank line below the menu */ 
panel create item(edit mode panel, PANEL MESSAGE, 
PANEL LABEL STRING, 


0); 


/* fit window around the editing mode panel */ 
window fit height (edit mode panel); 


) /* end create editing mode panel */ 
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create name panel() 
[KKK KKK KK KKK KKK KKK KKK KK KK KK KK KKK KKK KKK KKK KKK KK KK KA KKK KK KKK KKK KK KK KK KK KK 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: input name() 

CALLED BY: main() 


PURPOSE: This routine creates the panel which reads the names which 
are assigned to objects. It also registers the routine 
input name with the notifier. 


x k k x x x < k X < x x x K X X K K K Kk K k K X K K K K K K K k K K K K K K K K K K K K K K K K K K k K K K K K k K K K k K K K K K k K K K K. / 
{ 
/* put in a header */ 
object_name = panel_create_item(name_panel, PANEL TEXT, 


PANEL LABEL STRING, " Identifier Name:", 
PANEL VALUE, rei 

PANEL VALUE DISPLAY LENGTH,TEXT MAX LEN, 

0/5 g 


/* create read button and register input text with the notifier */ 
panel create item(name panel, PANEL BUTTON, 
PANEL LABEL IMAGE, panel button image(name panel, 
"read name", 0,0), 
PANEL NOTIFY PROC, input name, 
0); 


/* put top and bottom boundary on the panel */ 
window fit height (name panel); 


) /* end create name panel */ 
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create met panel() 
/ 5 8 A A KA X K X X k K o X K 2 E EK AXE 2 2 A A 2 XA 2 2 X AX XX 2222 2 7 sl iid Sen Sa J TU T DD d 


WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: input met() 

CALLED BY: main() 

PURPOSE: This routine creates the panel which reads the maximum 
execution times which are assigned to the operators. It 


also registers the routine input met with the notifier. 


X k K k k K k x k k K K K k k K k * k k k k k k K k k k k k k K k k k k k k k k k k k k k k k k k k k k K k k k Kk X K k K k k k k k k k k 1 K / 
( 
/* put in a header */ 
time constraint - panel create item(met panel, PANEL TEXT, 


PANEL LABEL STRING, " Max Exec Time :", 
PANEL VALUE , ME 

PANEL VALUE DISPLAY LENGTH,TIME MAX LEN, 

0); 


/* insert some spaces to align the read buttons */ 
panel create item(met panel, PANEL MESSAGE, 
PANEL LABEL STRING, " " 
0); 


/* create read met button and register input met with the notifier */ 
panel create item(met panel, PANEL BUTTON, 

PANEL LABEL IMAGE, panel button image(met panel, 

"read met", 0,0), 

PANEL NOTIFY PROC, input met, 

0); 


/* put top and bottom boundary on the panel */ 
window fit height (met panel); 


|) /* end create met panel */ 
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static Notify_value 


mode select (item, value, event) 
/ x x K X k K k k k k k k k k k k k X K K K K k K k K K X X KK K K k k K k k X X X K X K K K K k XK OI IOI III IIE III KG k 


WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: N/A 

CALLED BY: create editing mode panel() 


PURPOSE: This routine establishes the mode that the editor is 
operating in by setting the global variable edit mode to 
one of the predefined constants for the objects. 


K K K x K * K * X k k x K * k K K Kk kk * Kk k * K k K k K K K k K K k k K k k Kk K K k k K Kok ck kk ck k Kckokok ck kok ck ck E Xckok k k k k x / 
Panel_item item; 

int value; 

Event *event; 


switch(value) 


{ 
case OPERATOR: 


edit_mode OPERATOR; 


break; 


case DATA STREAM; 
edit mode 
break; 


I 


DATA STREAM; 


case SELF LOOP: 


edit mode - SELF LOOP; 
break; 
case INPUT: 
edit mode - INPUT; 
break; 
case QUTPUT: 
edit mode - OUTPUT; 
break; 
default: 
break; 
) 
return; 


) /* end mode select proc */ 
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quit proc() 


/ k kk Kk XX K kX k X k Kk 2 X X X K X K XK; KA X k KA Xk C A A 0 2 722272 E s ss 


WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: display error msg() 

CALLED BY: create editing mode panel() 


PURPOSE: This routine checks to see if the diagram has been 
Stored and if so, terminates the program and clears the 
display. If the diagram has not been saved it causes an 
error message to be displayed and does not terminate 
execution. 


K k K k k K k k k K k K k k x k K k k K k k k k k K k k k k k k k k k k k Xk k k k k k X k k Kk k k k k k k Kk k Kk K K K K K K K K KOK K K K K KO f 
{ 
if (graph_saved) 
{ 
/* destroy the window */ 
window set (frame, FRAME NO CONFIRM, TRUE, 0); 
window_destroy (frame) ; 


} 
else 


{ 
display error msg(6); /* graph not saved message */ 


)  /* end quatuprce +7 


84 


load proc() 


[RRR KR KKK KKK KKK KKK KKK KKK KKK KKK KK KKK KKK RK KKK KEK KKK KK KKK KKK KKK KK KKK KKK KKK 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: create op() 
append to op list () 
create line () 
append line to op() 
redraw diagram() 


CALLED BY: create operating mode panel() 


PURPOSE: This routine loads a diagram which is in the file 
graph.pic and causes it to be redrawn. 


ck ck ok ck ck cock ck ok ckck ck ok ckckok ckckokck ckck ck ck ck ck ck Kk ck kcKckckokockckckckckc ck k k k k k k k k k k k k k k k k k k k k k k k k k k k 1k X / 


{ 


int optype,xl,yl,x2,y2; 
Name *oname, 

*dest; 
Met “te; 


graph saved = 0; 
dgE-Stopenlgraphupicu erem). 


while (!feof(g)) 
{ 


oname = (Name *)malloc(sizeof (Name) ); /* alloc name storage 
fscanf (g,"%td\n",&optype) ; /* read in values 


fscanf(g,"$dWMn",&x1); 
fscanf (g,"%d\n", &y1); 
fscanf (g,"%d\n",&x2); 
fscanf(g,"%d\n",&y2); 
fscanf (g,"%sin",oname->string); 


oname->length = strlen(oname->string); /* calc name length 

if ((optype == OPERATOR) || (optype == EXTERNAL)) 

1 
te = (Met *)malloc(sizeof (Met)); /* alloc met storage 
fscanf(g,"$sMn",tc-»string): /* read met 
tc-»length = strlen(tc->string); /* calc met length 
op = create op(oname,optype,xl,yl,x2,y2,tc); /*alloc node 
append to op list(op list,op); /* attach node to list 

elise 

{ 
dest = (Name *)malloc(sizeof (Name));/*alloc dest name stg 
fscanf(g,"$sWMn",dest-»string); /* read dest name 


dest->length = strlen(dest->string);  /* calc name length 
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dop = create op(dest,optype,xl,yl,x2,y2,tc); /*alloc node */ 
ln = create_line(oname, optype, x1,y1,x2,y2,dop) ; /*alloc ln*/ 
append line to op(op,ln); /* attach line to its source */ 


} 
fclose (9); 
redraw diagram(); 


) /* end load proc */ 


store proc() 


f k k k k k k k k k k K k k k k k k k k k k k k Kk k k k k k K k k k k k k K k k k k k k k k k k k k K k k k k k k k k K k k k k k K k k k K K 
WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: create PSDL() 
store diagram() 


CALLED BY: create operating mode panel() 


PURPOSE: This routine stores the diagram in the file graph.pic. 
Prior to storing the diagram it causes the picture to be 
transformed into the equivalent PSDL link statements. 


K k K k k k k k k k k k k £ k k k K k k k k k k k k k k k k K k k k K k K k k k k K k k K k K K k k k K k k k K K k k k kckckck ck k kc kck k 1 / 
{ 

create PSDL(); 

store diagram(); 

graph saved - 1; 


) /* end store proc */ 
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static Notify value 


process canvas events (canvas,event) 


Jf C ek ck k k ck e k K K k K K K K K K k K K K K K K K K KOK K K K k K K K R K K ok K k k K k K K k k k k k k k k k kc ko kc kc kc k k x ox 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: pick line() 
delete line() 
pick operator () 
delete_op() 
redraw diagram() 
rubber band() 
process object () 


CALLED BY: main() 


PURPOSE: This routine processes canvas events. It determines what 
actions will take place for a given mouse event. 


X x K * x x k < x * k x x k k x k x k x k x £ x x x K k k X k k k k k k k K k k k k k k k k k k X x k k k k k k k k k K k k k k k X k k k K k / 


Canvas canvas; 
Event *event; 


( 


int id = event id(event); 
atc Mx Ei MEC 21, 
static int new posit = 1; 
staticline left button = 07 
static int middle button = 0; 
Operator *op; 

Line *ln; 


if (event is button(event)) 
{ 
if (event is down(event)) 
{ 
xl = event_x(event); 
yl = event y(event); 
switch (id) 
{ 
eme WE LEFT: 
new posit -1; 
x2 = xl; 
y2 yl; 
lett button=1; 
break; 


case MS_MIDDLE: 
break; 


/* check for button events 
/* check for down events 


/* position of button down event 


/* save starting posit 


/* do nothing 


07 


z 
=] 


> 


E 


Ny 


) 


case Mo RIGHT: /* pick object for wdclet ions 
if ((ln = pick line(op list,x1,y1)) !— NULL) 
{ 
op = NULL; 
delete line(op list,op,ln); 
} 
else if ((op= pick_operator(op_list,x1l,y1)) != NULL) 
delete op(op list,op); 
redraw diagram(); 
break; 
} 
} 
else if (event_is_up(event) ) / check eno peUpme Vents ma, 
{ 
switch (id) 
{ 
case MS LEFT: 
rubber band(x1,y1,x2,y2); /* blank out object */ 
x2 - event x(event); /* store new stop coords */ 
y2 = event y(event); 


process object (xl,y1l,x2,y2); /* draw final obj */ 
left button-0; 
break; 
case MS MIDDLE: Zsüdo nothing 
break; 
case MS RIGHT: VAS OE ETO 
break; 
) 
) 
} 
else if (id == LOC_DRAG) /* check for drag eventsg 


{ 
if (left_button) 
{ 
if (!new_posit) 
/* rubber band operator’s boundary while being drawn */ 
{ 


rubber band(xl,y1,x2,y2); /* erase previous image */ 
x2 = event x(event); /* get new stop coords */ 
y2 = event y(event); 

rubber band(x1l,y1,x2,y2); /* redraw the object */ 


) 
else 
new posit - 0; 


) 


return; 
/* end process canvas events */ 
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process object (xl,y1,x2,y2) 


[RRR KKK KR RK k k k X k k k K K k k k k k k k k k K k ke k k k k k k k k k k ke Ok Sk OK Ok Ok OK OK OK OK OK OEC OK Ok OK k k k K k k K K X K 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: pick operator () 
process operator () 
display error msg() 
process line() 


CALLED BY: process canvas events() 


PURPOSE: This routine determines if an object meets the criteria 
to be drawn. 


XCKCKCKCK OK CKCK CK KCk KC CK KCKCKCKCKCKCKCKCKCKCK CK X K k X X k X k k X K k k K k k Kckokck ckckckck k KC K Ck kckckok ck kc kck ck hc kc k kck ck ko / 


DES VT So MEUS 
{ 
Operator *op, *sop, *dop; 


switch (edit_mode) 


{ 
case OPERATOR: 

if (name checked && met checked) 

{ /* draw the object if it is*/ 
/* not positioned on top of*/ 
/* an existing object 2 

if  (((pick operator(op list,x1,y1))--NULL) && 
((pick operator(op list,x2,y2))--NULL)) 


process operator (OPERATOR, x1,y1,x2,y2); 


} 
else 


{ 
display error msg(4); /* name or met not checked */ 


} 
break; 


case DATA STREAM: 
if (name checked) 


í 
/* draw line if it starts and */ 


/* terminates on an operator */ 
if (((sop=pick operator(op list,x1,y1)) -NULL) && 
((dop=pick_operator(op list,x2,y2))!=NULL) && 
(sop != dop)) 


process line(DATA STREAM,xl,yl1,x2,y2,sop,dop); 
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) 


else 


( 


display error msg(5); /* name not checked */ 


) 


break; 


case SELF LOOP: 
if (name checked) 


{ 
/* draw the loop if it 


/* starts on an object and 
/* is not intersecting 
/* an existing object 
if (((sopszpick operator(op list,xl,y1))!-NULL) && 
((dop=pick operator(op list,x2,y2))==NULL)) 
{ 
process line(SELF LOOP,x1l,yl,x2,y2,sop,sop); 


) 
else 
{ 
display error msg(5); /* name not checked 


) 
break; 


case INPUT: 
if (name checked) 


{ 


/* draw line if it ends 
/* on an operator 
if (((sop=pick operator(op list,x1,y1l))==NULL) && 
((dop-pick operator(op list,x2,y2)) !=NULL)) 
{ 
process line(INPUT,x1,y1,x2,y2,sop,dop); 


} 
else 
{ 
display error msg(5); /* name not checked 
) 


break; 


case OUTPUT: 
if (name_checked) 
[ 
dop = NULL; 
/* draw the line if it 
/* starts on an operator 
/* and doesn't terminate on one 
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if (((sop=pick operator(op list,x1,y1))!=NULL) && 


((dop-pick operator(op list,x2,y2))--NULL)) 


process line (OUTPUT,xl,yl,x2,y2,Ssop,dop); 


} 
else 


{ 
/* name not checked */ 


display error msg(5); 
] 
break; 
default: 
break; 


! /* end process object */ 
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draw object (otype,xl,yl,x2,y2) 


[RRR IRR RIERA SER KICK RK ORR KOR NN k k k 2 2 2 ANID RRR RE A RAIN EN RPA) XW E S Os 


WRITTEN BY: R. K. Thorstenson 


LAST MODIFIED: 10 Nov 1988 


CALLS: N/A 
CALLED BY: process operator 


process line() 
redraw diagram() 


O 


PURPOSE: This routine causes the object to be drawn in final form. 


K K k k Kk k k k Kk K k k k k k k k k k k k k k k K K k k k k k k k k k k k K k k k k k k k K k k k k k k k k k k k k k K k k k kk kk kk k k / 


int otype,x1l,yl,x2,vy2; 


float i,xmid,ymid,xcent,ycent; 


int xnew,ynew,xold,yold; 


switch (otype) 


i 
case OPERATOR: 


xmid 
ymid 


(y2-y1)/2.0 


orc emite 
ycent 


= xl + xmid; 
yl + ymid; 


xold 
yold 


SUE P 
ycent; 


ee (a ce (s 


( 


xcent + 
ycent + 


xnew = 
ynew 


pw vector(drawing pw, xold, yold, xnew, ynew, PIX SRC, 


1); 
xold = 
yolda 


Xnew; 
ynew; 
J 

break; 


(x2—x1)/2.0; 


<A ale 


/* calc objects midpoint 


/* objects center point on the screen 


/* position to start drawing the object 


/* loop to draw the object 
i = i + PI / 12) 
/* draw line segments of an oval 
(xnid * cos(i)); 


(ymi eA eS erie) Be, 
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case DATA STREAM: 
/* draw line from (xzl,y1) to (x2,y2) */ 
pw vector(drawing pw, xl, yl, x2, y2, PIX SRC, 1); 
break; 


case SELF LOOP: 
/* draw three sides of a rectangle */ 
pw vector(drawing pw, x2, yl, x2, y2, PIX SRC, 1); 
pw vector(drawing pw, x2, y2, x1, y2, PIX SRC, 1); 
pw vector(drawing pw, xl, y2, xl, yl, PIX SRC, 1); 
break; 


case INPUT: 
/* draw line from (xl,yl) to (x2,y2) */ 
Ppw_vector (drawing pw, xl, yl, x2, y2, PIX_SRC, 1); 
break; 


case OUTPUT: 
/* draw line from (xl,yl) to (x2,y2) */ 
pw vector(drawing pw, xl, yl, x2, y2, PIX SRC, 1); 
break; 


default 
break; 


) /* end draw object */ 


rubber_band(x1,y1,x2,y2) 


J x k 2 X XI; X X X k X KOK k X k X X X X X K A A X X X K X X X AERIAL ARIA RA) A ae NER NR ALB RGA TK ENDS ONU LE 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 

CALLS: N/A 

CALLED BY: process canvas events() 


PURPOSE: This routine draws the object during the rubber banding 
process. An operator is drawn as a rectangle by this 
routine. 


k k k k k k k k k k k k k k k k k k k K ko K K k K k k kO k KO K k K KOK KOK KOK O Koko k KO KOK kO KOK KO KOK K KOK KO KO KOK KOK KOK KOR KOR / 
int xl,yl,z2,y2; 
{ 
switch(edit mode) 
{ 
case OPERATOR: 
pw_vector (drawing pw, xl, yl, x2, yl, PIX NOT(PIX DST), 1); 
pw vector(drawing pw, x2, yl, x2, y2, PIX NOT(PIX DST), 1); 
pw vector(drawing pw, x2, y2, xl, y2, PIX NOT(PIX DST), 1); 
pw vector(drawing pw, xl, y2, xl, yl, PIX_NOT(PIX DST), 1); 
break; 


case DATA_STREAM: 
pw vector(drawing pw, xl, yl, x2, y2, PIX NOT(PIX DST), 1); 
break; 


case SELF LOOP: 
pw vector(drawing pw, x2, yl, x2, y2, PIX NOT(PIX DST), 1); 
pw vector(drawing pw, x2, y2, xl, y2, PIX NOT(PIX DST), 1); 
pw vector(drawing pw, xl, y2, xl, yl, PIX NOT(PIX DST), 1); 
break; 


case INPUT: 
pw vector(drawing pw, xl, yl, x2, y2, PIX NOT(PIX DST), 1); 
break; 


case OUTPUT: 
pw vector(drawing pw, xl, yl, x2, y2, PIX NOT(PIX DST), 1); 
break; 


default: 
break; 
] 
) /* end rubber band */ 
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process_operator(otype,x1l,yl,x2,y2) 
J| k k k k k k k k k k k k k k k K k K k k K k k k k k K K K K k K & K K & £ £ K £ £ £ £ £ k £ £ k £ & k £ £ k & £ £ k k ck ok ok ko k ck k ko ko 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: draw object () 
get met () 
display name() 
display met () 
create op() 
append to op list () 


CALLED BY: process object () 


PURPOSE: This routine manages the process of drawing, labeling, 
Storing,and linking an operator. 


XCKCKCkCk kk Ck Ck Ck kk kk Ck k ck ck ck ck kk kh kck ck kk Ch kc k k ck ck kck ck ck ck kck kck k kc k ck kk kc Ck k ck kc kc k ck ck k kc k ck k k k ko k X / 


mt oc ye x 1 yl x2ny25 


Name *obj name; 
MOC; 
Operator *op; 


draw object (otype,xl,yl,x2,y2); 

se = čs (1381) 

obj name = get name(); 

display name (obj name,otype,xl,yl,x2,y2); 
display mereci yl, x2 y2). 

op = create op(obj name,otype,xl,y1,x2,y2,tc); 
append to op list(op list,op); 

name checked = 0; 

met checked - 0; 


} /* end process_operator */ 


Do 


process_line(otype,x1l,yl,x2,y2,sop,dop) 


J KOK K X K X X K XIX X Xk k X X X X Z XIX X K X X X K X X X? ki; x X A KK DA GR OD ON NX DER USC EX DR UE EA T 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: draw object () 
draw arrowhead() 
get met () 
external() 
create op() 
append to op list() 
get name () 
display name () 
create line() 
append line to op() 


CALLED BY: process object () 


PURPOSE: This routine manages the process of drawing, labeling, 
storing, an linking lines. 


X k k k k k k k x k k k k k k k k K Kk K K K K K K k K KOK KOK K K K K K K K OR KOK K KO KOR K KOR KOR KOK RK R R RK KOR R R KO KOR KOR RO RO KO RO / 


int otype,xl,yl,x2,y2; 
Operator *sop,*dop; 


{ 
Name *obj name,*op name; 
Line *ln; 


draw object (otype,xl,y1,x2,y2); 
if (otype -- SELF LOOP) 

draw arrowhead(x2,y2,x2,yl); 
else 

draw arrowhead(xl,yl,x2,y2); 


if (otype == INPUT) 
{ 
tc = get met(); 
op name = external(); 
sop = create op(op name,EXTERNAL,xl,yl,x2,y2,tc); 
append_to_op_ list (op_list,sop); 
) 
obj name - get name(); 
display name(obj name,otype,xl,yl,x2,y2):; 
ln = create line(obj name,otype,xl,yl,x2,y2,dop); 
append line to op(sop,ln); 
name checked - 0; 


) /* end process line */ 
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Ope 
ECTO 


/** 


Kx x 


rator * 
ate op(name,op_type,x1,yl,x2,y2,tc) 


KKK KEK KKK KKK KKK KKK KKK KKK KK KK KE KKK KKK EK KKK EK KEK KKK KKK KEK KKK KKK KKK KKK KKK 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: alloc_operator () 
CALLED BY: load proc() 
process operator () 


process line() 


PURPOSE: This routine stores all the info for an operator in a 
Structure- 


K k k K x k Kk X x Kk X k k X k k k k k k k k k X k k k K k k X K k K K k k k k k k k k k k k k k k k Kk k ck kk ke ee / 


Name *name; 


int 
Met 
( 


) 


op type,xl,yl,x2,y2; 
tc 


Operator *new op; 
new op = alloc operatorí(); /* get storage for the operator */ 
/* fill in the values for the operator */ 

new op->name = name; 
new op-»met = tc; 
new op->head = NULL; 
new op->tail = NULL; 
new op->next = NULL; 
switch(op type) 
{ 

case OPERATOR: 

new_op->optype = OPERATOR; 


new op->xstart = xl; 
new op->ystart = yl; 
new op->xstop = x2; 
new op->ystop = y2; 


break; 
case EXTERNAL: 
new Oop->optype = EXTERNAL; 


new op->xstart = 0; 
new op->ystart = 0; 
new op->xstop = 0; 
new op->ystop = 0; 
break; 

default: 
break; 


) 
return (new op); 
/* end create op */ 


Line 


* 


create line(name,ln type,xl,yl,x2,y2,dest op) 
f * k k k k k K k k k e ehe k k k k k k K k hok ce k ke e k k K k k K k k K K K K kk Tk he ke e he he khe e kc KO K KO KO e e ke ke e KO KO K KOK ke ke e 


WRITTEN BY: R. K. Thorstenson 


LAST MODIFIED: 10 Nov 1988 


CALLS: alloc line() 


CALLED BY: load proc() 


process line() 


PURPOSE: This routine stores the information for a line in a line 


structure. 


* & * k k kc ok k k k k k k k k k k k k k k k k k k k Kk k k k k k k ke ok ok k K k K K kok k k k kO K kO KO kO Kok k KO K k K K K kO k k k k k / 


Name 
int 
int 


Operator 


{ 


Line 


*name; 
ln_type; 
PN 
*dest op; 


*new ln; 


new_ln = alloc_line(); 


/* get storage for the line */ 
g 


/* fill in the values for the line */ 


new_ln->name = name; 
nevin e xstarti= ki; 
new_ln->ystart = yl; 
new_ln->xstop = x2; 
new_ln->ystop = y2; 
new_ln->next = NULL; 
switch(ln type) 


{ 


case INPUT: 


new_ln->lntype = 
zEcesuMOE ame 


new ln-»dest 
break; 


case DATA STREAM: 


new ln-»lntype = 


new ln-»dest 
break; 


case OUTPUT: 


new_ln->lntype = 
= external(); 


new_ln->dest 
break; 


case SELF LOOP: 
new_ln->lntype 
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INPUT; 


DATA_STREAM; 


dest op->name; 


CU TPT 


SELF LOOP; 


new ln-»dest = dest op->name; 
break; 


default: 
break; 
] 


return(new ln); 


) /* end create line */ 


delete op(op list,op) 


f ORC echec ke ke e he e kh ke e kk kk kk e ke ke e ke ke ek e kh kk ke Kk e ke e kk X k X k K X kc ke E ke KK KKK KK 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 

CALLS: delete input lines () 

CALLED BY: process canvas events () 


PURPOSE: This routine deletes an operator from the list of 
operators and frees up the storage. 


X X x k x K K k k k 2 k kk K kk K kk k kk K K Á IK OK OK OK RK KKK RK RK RAK KK KKK KK / 


Operator list *op list; 
Operator *op; 


Operator *dptr, 


. *Otemp; 
Line Sper, 
*ltemp; 
Name Sm 


/* find lines which terminate on 
/* this operator and delete them 
n = op-»name; 
delete input lines(op list,n); 


otemp = op list->head; /* put pointer at head of op list 
if (op != otemp) /* is the first op the one to delete? 
while (otemp->next != op) /* if not, find the one to delete 


{ 
otemp = otemp->next; 


} 
dptr = otemp->next; /* unlink the op to be deleted 


oo 


2 
*/ 


B" 


z 


xf 


2 


if (dptr->next != NULL) 


{ 


otemp->next = dptr->next; 


dptr->next = NULL; 
) 
else 
otemp->next = NULL; 
) 
else 
{ 
dptr = op list->head; 


/* the first one is the one to delete */ 


/* unlink the first op */ 


op list->head = dptr->next; 


) 
if (dptr->head != NULL) 


{ 


ltemp = dptr->head; 
lptr = dptr->head; 
dptr->head = NULL; 


while (lptr->next 
{ 
lptr = lptr->next; 
free (ltemp); 
ltemp = lptr; 
) 
free(lptr); 
lptr = NULL; 
ltemp = NULL; 
) 
free(dptr); 
dptr = NULL; 


J ercide Tereon. 


x / 


/* does it have any assoc lines ? 


/* if so, free up their storage */ 


!= NULL) 


/* free up the last line's storage */ 


/* free up the operator's storage */ 
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delete input lines(op list,n) 


/ x * x x x x * x x < x < x * < x * k x x k x x x x x x 1 k x Xk X k X X X X < X X K k k k k k K k k k k k k k k X k k Kk k k k K K K K k k K K K 


WRITTEN BY: R. K. Thorstenson 

LAST MODIFIED: 10 Nov 1988 

CALLS: delete line() 

CALLED BY: delete op() 

PURPOSE: This routine finds all of the input lines for an 


operator which has been deleted and causes them to be 
deleted. 


* K k x < k k k k K k k k k x k K k k k X k k k k k k x k k k K k k k k k k k k k k k X k k k K k 1 k k k k k k k k k k k k k k k k k k x x x / 


Operator list *op list; 
Name *n; 


Operator *optr; 


Line ES eb 
*ltemp; 
optr = op list->head; /* start at head of operator list 
while(optr != NULL) /* search the entire list of operators 
( 
lptr = optr->head; /* start inner ptr at head of line list 
while(iptr != NULL) /* check each line leaving each operator 


{ 
if(!strcmp(n-»string,lptr-»dest-»string)) 
( 
ltemp = lptr->next; 
/* found a line with the 
/* destination searched for 
delete line(op list,optr,lptr); /* so delete it 
iptr = ltemp; 
) 
else 
{ 
lptr = lptr->next; /* go to the next line 


) 


optr = optr->next; /* go to the next operator 


/* end delete input lines */ 
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f 
2 


xf 
ay 


e 


x 


nf 


wy 
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delete line(op list,op,ln) 


[RRR RRR IA eR AIX X oko o O OD DKK ak 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 


CALLED BY: delete input lines() 
process canvas events .() 


PURPOSE: This routine deletes a line from an operator's line 


list. If the source operator is not known, it will search 


through all of thelists until it is found. 


* k k K k k k k k X? k k k K k k K k k k K * k k k K k k K k K OK K k K Kok KOK k KOK k K Kok K K k k Ok k Kok k k k k kO k Ok ko ko ko kk kj 


Operarorfiisr g: opsi ses 
Operator SO 
Line DĚ 


Operator *optr; 


Line ENS Cor, 
*ltemp; 
int ln found = 0; 
if(op != NULL) /* the line's source op is known 
{ 
optr = op; /* start the search for the line at its source op 


lptr - optr-»head; 
ltemp - lptr; 


while(lptr !- ln) /* skip the lines which don't match 


( 
ltemp = lptr; 
lptr MUI tcm ente 


) 


else /* source op is unknown - find the line 
{ 
optr = op list->head; /* start at beginning of op list 
while((optr !- NULL) && (!1ln found)) /* search until found 
{ 
lptr = optr->head; /* start at head of line list 
ltemp = lptr; 
while((lptr != NULL) && (!ln found)) /*search line list 
{ 
if (lptr == ln) /* found the line 


{ 
Ine ouno mi 
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T 


z 


T 


x 


7 
ey 


ny 


a 
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else 

{ 
ltemp = lptr; /* skip to next line 
lptr = lptr->next; 


if (!ln found) 
optr = optr-»next; /*search next operator's line list 


/* unlink the line and free its storage 
if (ltemp == lptr) /* delete first line on list 
{ 

optr->head = ltemp->next; 
lptr->next = NULL; 
ltemp = NULL; 
if (optr->head == NULL) /* first line was the only line 
{ 
optr->tail = NULL; 
) 
) 
else if(lptr == optr->tail) /* delete last line from the list 
{ 
ltemp->next = NULL; 
optr->tail = ltemp; 
) 
else /* delete a middle line from the list 
[ 
ltemp->next = lptr->next; 
lptr->next = NULL; 
} 
free(lptr); 
optr = NULL; 


) /* end delete line */ 
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xy 


xd 


E 
*/ 
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*/ 


Operator * 
pick operator(op list,xpick,ypick) 
J SKK ck Ok kk kk Ck K KUKUK OK CK OK DK OK UOK OK UK KK DA UK OK CX UK OK XR KR Kk Do Gc UE UK occu cR vox ARCA OSEAN he ee s 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: is op pick() 


CALLED BY: process canvas events() 
process object () 


PURPOSE: This routine determines if a data stream or output 
line starts on an operator. If so, it returns a pointer to 
that operator. 


K K K k k k k k k k k K k k k k k k k k k Kk k k k k k Kk k k Kk k Kk k k k k k k k K k k Kk k k k k k Kk k k k k k k k k k k k k k k Kk k k k k k K. j 
PETA © TS MN ES E 
int Scri MC 


OPETACOD P 


/* search operator list */ 
for (ptr = op list->head; ptr != NULL; ptr = ptr->next) 
{ 
if (ptr->optype == OPERATOR) /* skip the null operators */ 
{ 
CES for pecki 
if (is op pick(ptr->xstart, ptr->ystart, 
ptr->xstop, ptr->ystop, xpick, ypick)) 
( 


return(ptr); 
) 
return (NULL); 


|) /* end pick operator */ 
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nre SNODSEpick( iyd x20ny2rnxpnyp) 


/ K k x x k k x K k k K k K k K K k k k k k k k k k X K k K K Kk K K K K K k K K k k k K k k K K X X X k k k K k X K K X k k K k k k K K X K K K 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: pick operator () 


PURPOSE: This routine determines if a pick has occurred within 
the bounds of an operator. 


XCkOKCKCk k k x K 1k x k ck ck k K Ck Ck k k K kc kok ck k Kok ck KCkck CK CKCkCK Ck Ck k KC CK k ck Kok ck k kck ck Ck Kok ck ck kc kckck ck kc kckokckckok / 


int SSMUS 21, XO Yp: 


if (( (xp > x1) && (xp < x2) && (yp > yl) && (yp < y2) )11 
( (xp < xl) && (xp > x2) && (yp > yl) && (yp < y2) )!| 
( (xp < xl) && (xp > x2) && (yp < yl) && (yp > y2) )II 
( (xp > xl) && (xp < x2) && (yp < yl) && (yp > y2) )) 


return(1); 
else 
return(0); 


jee enc 2s cp pick */ 
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rines 
pick line(op list,xpick,ypick) 


[A K k x k k 1 x x x * k * x k * x x < x k k x x k k k k k k k k k K k k K K K K k k K k K k k k k k k k K k k k k k K k O K K K K K K K K K K 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 

CALLS: is line pick() 

CALLED BY: process canvas events () 


PURPOSE: This routine scans each operator's line list checking 
for a line which has been picked. 


KKKKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK KKK KKK KKK KKK KKK RK KKK KK KK KK / 


OpenatcoraE st ODONIS 
int xpick, ypick; 


Operator *optr; 


Line ame estar 
/* scan the operator list 
for (optr = op list->head; optr != NULL; optr = optr->next) 
{ 
/* scan each line list 
for (lptr = optr->head; lptr != NULL; lptr = lptr->next) 


[ 
/* test for pick 


if (is dine piek(lptr—>xstart, Iptr—--ystare, 
lptr->xstop, lptr->ystop, xpick, ypick)) 
{ 
return (lptr); 


} 
return (NULL) ; 


) /* enarpiek Tine */ 
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int is_line _pick(xl,yl,x2,y2,xp,yp) 


[ORR RI k x x 1 1 k k k k k K k k k k k k k k k K k k k K X Kk K k K K K Kk k K K k K K K K K k K K K K K K K K K K K K K K R K K K K K K K K. 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: pick line() 


PURPOSE: This routine checks to see if a pick has occurred 
within the pick region of a line. 


x K x x x k K x k K K x x * k K k K K K k K x k k k k k k k k k K K X TR k K k k X k K Kk k k K k k Kk k k K k Kk K k k k K K k K K k K / 


int xl, yl, x2, y2, XP, YP? 


/* is (xp,yp) within pick region of a line? */ 
if (( (abs (xl-xp)+abs(yl-yp)) < PROXIMITY) || 
( (abs (x2-xp)+abs(y2-yp)) < PROXIMITY) ) 


return(1); 
else 


return (0); 


end is line pick */ 
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append to op list(op list,op) 


[RRR RRR RK AR AIK AK KKK KR eK RRR AAR RIA KIRK) Ri Ae ARR ARR RGR XK RRR t 7 s 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 


CALLED BY: load proc() 
process operator () 
process line() 


PURPOSE: This routine attaches a newly created operator to the 
list of operators. 


* k K k K K K k * k K k K k k k k k k k k k k k k Kk * K k * k k K K k k x k k k k k K k k k k k k k k k k k k k k K k k k k k k K K k k k k K / 
Operator_list *op list; 
Operator *op; 


if (op list->head == NULL) 

{ 
op list->head = op; /* attach first operator to list */ 
ga distres op; 


) 


else 


{ 
op list->tail->next = op; /* attach operator to end of list */ 
op list->tail = op; 


) /* end append to op list */ 
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append line to op(op,ln) 


J * x x k k k x k k X k k k k k k K k K k k K k K K k k K k k k K K K k k K K k k k K k k k k k K k k k k X k K K k X K K K K K k K k K K ko X Ck 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 


CALLED BY: load proc() 
process line() 


PURPOSE: This routine attaches lines which depart an operator to that 
operator's list of output lines. 


* K k K k K k k k k k k K k k k k K Kk kk k k k k k k k Xx k k k k k k k k K k k k k k K k k k K k k sk ke k k k k k ck k k K K K X X K K K K / 


@perator *op; 
Line sir 


if (op->head == NULL) 


{ 
op->head = ln; VSA BEC NE SEE EOS 177 


op->tail = ln; 
) 
else 


[ 
op->tail->next = ln; /* attach to end of line list */ 


op->tail = ln; 


) /* end append line to op */ 
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Operator * 


alloc operator () 
J k k k k k Kk cR DR X K k K k K k 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: create op() 


PURPOSE: This routine allocates the storage for an operator 
Structure. 


* k k k k k ok Ck AZ AZ ZÁ K Á k * K k k k k X k k k k k k k k k k k k k k k k K k K Kk k k K k k k K k k K k K K k k K k k k k k kck ck k  [ 


{ 
Operator *op; 


op = (Operator *)malloc(sizeof (Operator) ); 
return (op); 


} /* end allec operator */ 


Line * 
alloc line() 
/ 8 k k k k k k k ;k k k k ke k k k k k k k k k k k k k k k k k k k k k k k k KEK KK KR KKK KK RK KKK KKK KK KK KKK KKK KKK KK 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CAE FNE) 


PURPOSE: This routine allocates the storage for a line structure. 


XCkCKCkCkCkCkCkCkCkCk KCkCkCKCkckck ck Ck kckckck kck ck ckckc kokckck Ck ckckck ck ckckckck ck Á ZÁ K A KAZ Á kckckck ck kc kok ck ck kckckckckckckck ck 


{ 


Line *ln; 


ln = (Line *)malloc(sizeof (Line) ); 
return (ln); 


} #8 Sac suübexe dome 9 
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input name(item, value, event) 


/** 


X k x k x K Kx x * k x K Kk x k k kk K K e c ce oe oc c ce cc ook cc e oc c cc c ok ce OK c c oc oc oic ce c ce cce e ee ce ce ceo e eo oo XXX 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: is valid ada id() 
display error msg() 


CALLED BY: create name panel() 
PURPOSE: This routine reads the names from the name panel and 


checks to see if they are valid ada identifier names. If 
they are invalid,an error message is displayed. 


K K K x k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k kc k ck ck ck kc k kc k ck ko k ok f 
Panel_item item; 

int value; 

Event *event; 


i 


/* get storage for the string */ 
name buf - malloc(40); 
/* initialize the storage */ 
name buf[0] = ‘\0'; 


/* read the users string from the display */ 
strcpy(name buf, (char *)panel get value(object name)); 


/* check to see if the name is an ada identifier */ 
if (is valid ada id(name buf)) 
{ 
display error msg(1); /* blank out the error message area */ 
name checked - 1; 
} 
else 
{ 


display error msg(2); /* invalid ada id message */ 


/* end input name */ 


bti 


display error msg(msg id) 
ff BRIER RA A KKK KR ATR KKK ARIA HARIRI AK AIRY A) I ISS IR) ON DR EON UK KK A AU A DK A X E A A XL ELA E LRL 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 


CALLED BY. quit proc) 
process_object () 
input_name () 
input_met () 


PURPOSE: This routine displays error messages on the canvas 
in response to checks made throughout the system. A numeric 
code signifies which message to display. 


x x k xxx II IO I IOI IO IO II TO k ck ckck kh ck k ck kc k Ck kck kc kc k k k k kc kck k k kk k k k / 
int msg id; 


char  *message; 


message - malloc(45); 
switch(msg id) 
{ 


case 1: 
message = " s 
break; 

case 2: 
message - "SYNTAX ERROR in ADA identifier A 
break; 

case 3: 
message - "SYNTAX ERROR in Maximum Execution Time ME 
break; 

case 4: 
message = "ERROR - Either NAME or MET not read Pa 
break; 

case 5: 
message = "ERROR - NAME not read n 
break; 

case 6: 
message = "WARNING - The graph has not been stored! ur 
break; 

default: 
message - ""; 
break; 


} 
pw_text (canvas_pixwin (drawing canvas),150,15,PIX_SRC, NULL,message) ; 


) /* end display error msg */ 
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Name * 


get name () 
f| CROCO KC kk kk ek kk kk koc kk ck ck kc kk kck ck ck kc k ck ok ck ck ck ck ck ck kc k ok kc kc kckckck ok ckck ck okck ckokck ok ck ok ko kokokokok 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 


CALLED BY: process operator() 
process line() 


PURPOSE: This routine allocates the storage required for 
a name, stores the name in the structure, and returns a 
oun oM 


£ x x x * x x k K x x x k Z Ck CK K k k K k x * K K k K x X X K k X K k X Kk k X X K K X X K Kk Kk K k K K k K K K K k k k K k k k k k ck k k xk / 


{ 


Name *n; 


/* get storage for the name */ 
n = (Name *)malloc (sizeof (Name) ); 
/* assign the name to this storage */ 
Strcpy(n-»string,name buf); 
/* find the name's length */ 
n->length = strlen(n->string); 
return(n); 


) /* end get name */ 


Jo 


display name (n,otype,xl,yl,x2,y2) 


J k 2 * * * < k k k k x * < x ec ko kk Ck kc kk kk < K k k K k * < k K k k K k K k < k k k k k k k k k k k k k k k k K k k k K k K K k k K 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: process operator() 


process line() 
redraw diagram() 


PURPOSE: This routine displays the name of an object which 
the user has drawn. 


* * k * * k * x k * x * ke k k < x x < k x x ke e kc koe ke x k k k x x k x k k ke k k k kc oe oe ke kc kc ke ke k k k k K e c ke kk kc e ek / 
Name  *n; 
int otype,xl,yl,x2,y2; 


float  xcent,ycent; 
/* calc center of the object */ 


xcent = xl + ((x2 - x1) / 2.0); 
ycent SAL se (092 o Wil) 7 Za) eg 


switch (otype) 
{ 
case OPERATOR: 
pw text(canvas pixwin(drawing canvas), 
(int) xcent- ( (n-»length)/2)*8, 
(int) ycent+5,PIX_SRC,NULL,n->string); 
break; 


case INPUT: 
pw_text (canvas pixwin (drawing canvas),xl,yl, 
PIX SRC, NULL,n->string); 
break; 


case OUTPUT: 
pw text (canvas pixwin(drawing canvas),x2,y2, 
PIX SRC, NULL,n->string); 
break; 


case DATA STREAM: 
xcent = (62 = A) / 250 
ycent (y2 - yl) / 2.0; 
pw_text (canvas _pixwin(drawing canvas), 
xl+(int)xcent,yl+(int)ycent,PIX SRC, 
NULL,n->string); 
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break; 


case SELF LOOP: 
pw text(canvas pixwin(drawing canvas), 
(int) xcent-((n->length) /2) *8, 
(int)y2-7,PIX SRC,NULL,n->string); 
break; 
default: 


break; 
) 


) /* end display name */ 


ie 


erate 
is_valid_ada_id(name_buf) 
f| 2 x k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k K k k k K K k k K k K K K k k k K K k K 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: input name () 


PURPOSE: This routine checks to see if a name is a legal ada 
identifier 


FOI I I II IOI kc Ok kk ck ck ck Ok kc kk kk ck ck ck kck Ck ck ck ck ckck ck ck ck k k ck k ck ck k ck ck k ko kc k ck ko k ck ko k x / 


char name buf[40]; 


agn space found = 0; 
int 1 = 1; 


if (isalpha(name_buf[0])) 
{ 


while (1 <= sstrlem (char *)mame but) - 1) 
{ 
if (!isgraph (name_buf[i])) 
{ 
space found = 1; 
DE CC Uz 
} 
else if (((isalnum(name_buf[i])) || 
(name_buf[i]==' !))&& !(space found)) 


else 


{ 


return (0); 


) 


return (1); 


} 
else 


{ 


return (0); 


) 7* end as  validvadamide <7 
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input_met (item, value, event) 


[RRR < k k k k k k k k k k k k k k KOK K K S k k kk k ak k k ak k K K k k k IO I ck ck IK TO IK ak IO IT IC ek 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: is valid met () 
display error msg() 


CALLED BY: create met panel() 
PURPOSE: This routine reads a MET from the met panel and checks 


to see if it is valid. If it is not, an error message 
is generated. 


Ck kCkCk kCk Ck kCk KCk Z KAZ k ck kck ck kck kck k Xckckck k ck kCk ck kc k k ck kc kc kck k kck kCk kCk Ck k kc kck kc k kc kc k ck kck kck ck kk k kk k / 


Panel item item; 
int value; 
Event *event; 


{ 
/* get storage for the met value 
met_buf = malloc(12); 
/* initialize 
met_buf[0] = 'N0”; 


/* read in the met string 
strcpy (met buf, (char *)panel get value(time constraint)); 
if (is valid met (met buf)) 
{ 
display error msg(1); /* blank out the message area 
met checked - 1; 
} 
else 
{ 


display error msg(3); /* invalid met 


) /* end input met */ 
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int 
is valid met (met buf) 
[RK RR KKK KK KK KK KK KKK IK ke ke ke Sk hk KK KK IK IK KKK IK KK KKK KKK KKK KKK KKK KKK KKK KKK KK KK 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: is valid met () 


PURPOSE: This routine checks an MET to see if it has the proper 
syntax. 


1 k * k k k k k k k k * x k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k K k k k K k K k k k k k K k k k K K. / 


char met buf[12]; 


int nondigit found - 0; 
int letter prev found = 0; 
int mfound = 0; 

int ufound = 0; 

Hirn ta done 70; 

arita j = als 


if (isdigit (met_buf[0])) 
' while (i <= strlen((char ne o uc MEE) 
i if (!isalnum(met buf[i])) 
| return(0); 


) 
else if (isdigit (met buf[i])&&!'nondigit found) 


else rfo0rsdigitümetebstp3])) 
( 
return(0); 
) 
else 
( 
nondigit found = 1; 
switch(met buf[i]) 
case 'u'; if (!letter prev found) 
( 
ufound - 1; 
rette rac VI OUT il. 
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else 
{ 
return (0); 


} 
break; 


cases MM ette rev O UNA) 
{ 
letter_prev_found = 1; 
DEC I. 
} 
else if ((ufound| |mfound) &&!done) 
{ 
done = 1; 
qM NEC TN, 
) 
else 


{ 


return(0); 
} 
break; 


case 'm': if (!letter_prev_found) 

{ 
mfound = 1; 
letteriprev found- I; 
isi t l; 

} 

alse 

{ 
return(0); 


} 
break; 


default : return(0); 
break; 


} 
if ((ufoundé&&!done) || (!nondigit_found) ) 


return (0) ; 


} 


else 


{ 


return (0); 


} 
jee end asivalid met */ 


Duo 


Met * 


get met() 
f Z k k k k k k x k k K k k k k k Kk k k k k ke ke k ke kk ke k k ke ke k k k k k k K K k k k k K K K K K K OK k K ke k KOK K KOK e hk he ek hex 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 


CALLED BY: process operator() 
process line () 


PURPOSE: This routine allocates a storage structure for a 
MET and fills it in with the MET which has been entered. 
It then returns a pointer to this structure. 


* k * k k x k k * k k k k k K K K K k k Kk K K k K K K KOK K K K KOK KOK K K K K K K K KOK KOK KOK KOK KOR KOR KOR KOR KOR R KOR KOR R OR ke kx f 


{ 
Met *tc; 


/* get storage for the met */ 
tc - (Met *)malloc(sizeof (Met)): 


switch(edit mode) 
{ 
case OPERATOR: 
/* assign the input string to this storage */ 
strcpy(tc-»string,met buf); 
/* find the length of the string */ 
te->length = strlen(tc->string); 
break; 


CaSCENE UT: 
SPECPV ČES G0 S) 
te->length = 2; 
break; 


default: 
break; 


} 


return (tc); 


} /* end get_met */ 
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display met (tc,xl,yl,x2,y2) 


[RR Ke ke k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k K k k K k k k k k k k k k k k k k k k k K k k K 


KKK 


Met 
Ine 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 


CALLED BY: process operator() 
redraw diagram() 


PURPOSE: This routine displays an operator's MET in a position 
centered directly above it. 


K k K K K k k x k k K k x K Kk k k k k X K K K k k X K k k K k k K k k k K K K K K K K K K K K k k K K k K k R K k k K k k k K K K K K X / 
itis 
EI PESO MS. 


float  xcent; 


meent = xl +x? = xl) / 2.0); 

pw text(canvas pixwin(drawing canvas), 
(int) xcent- ((tc->length)/2)*8, 
(int)y1-5,PIX SRC,NULL,tc-»string):; 


/* end display met */ 


reel 


Name * 


external() 
[RRR RRR RAK KKK RA KKK KKK AAA KOK KERALA RAI RIK KIRK KIRK ERIK RRR, RIA xus p cc EE DRE 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 
CALLED BY: process_line() 
PURPOSE: This routine returns the name “EXTERNAL whenever 
it is called. EXTERNAL is the name of the source operator 


for all input lines and the destination of all output 
lines. 


* k * III IO OIC k k K k K k k K K K K K k K K K K K K K K K R K K R KOK K KOR RR R RK R R R R K K R OR R R KOR R R KO KO f 


{ 


Name *n; 

n = (Name *)malloc(sizeof (Name) ); /* alloc storage */ 
strepy (n->string, "EXTERNAL") ; /* assign name */ 
n->length = 8; /* assign name */ 


return(n); 


) /* end external */ 
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create_PSDL() 


[RRR KK KKK RR KK KKK KKK KKK KKK KR KK KK RK KK KKK KR KK KK KK RK KR RK KK ek ek 


WRITTEN BY: R. K. Thorstensen 

LAST MODIFIED: 10 Nov 1988 

CALLS: N/A 

CALLED BY: store proc() 

PURPOSE: This routine creates the PSDL statements represented 
by the user's data flow diagram. A PSDL statement of the 
form 


output line name.source name[:met]-->destination name 


will be constructed from the information contained in the 
operator list. 


X K K K k k k K k k K k k K k k k < k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k k ko k ko kx kx / 


( 


Operator *op ptr; 


Line *output ptr; 
char *psdl; 

char tperiod = u.i; 
char SOU O P r" "> 
char xarrew =” >". 


f - fopen("graph.link","w"); 
psdl = malloc(150); 
op ptr = op list->head; /* point at head of the operator list */ 
while(op ptr != NULL) 
{ 
output ptr = op ptr->head; /* pt line ptr at head of line list*/ 
while(output_ptr != NULL) 
{ 
/* assemble the psdl statement by */ 
/* concatenating the parts of the */ 
/* PSDL statements together */ 
psdl = streat (psdl, output ptr->name->string); 
psdl = strcat (psdl,period); 


psdl = strceat (psdl,op ptr->name->string) ; 
if ((op ptr->optype == OPERATOR) && /* put in met for op */ 
(OPP Me S no OE) 


psdl = strcat (psdl,colon); 
psdl strcat (psdl,op ptr->met->string); 


) 
psdl = strcat(psdl,arrow); 
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} 


} 


} 


psdl = strcat (psdl,output ptr->dest->string); 

fprintf (f, "s\n" psd), /* store link stmt in file */ 
psal[0)j = "N0'; (Arena 127, 
output ptr = output ptr->next; 


ODE CIO INE 


feculo sete) i. 


/* 


endacreateNpop 
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store_diagram() 
J| x x x x k k x x k x X X k X k k X K K X X k K K K X K K X K K K k K k K K K k K K K Ok K k k K k k K K k K k k X k? K K k k K k k k K K k K 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 
CALLS: N/A 

CALLED BY: store proc () 


PURPOSE: This routine stores the contents of the entire 
Storage structure for the diagram in a file named 
graph.pic. It writes out each operator followed 
immediately by the lines which leave it. 


K x * KK k k k k k k k k kx k x k k k k k k k X £ “< K k k K k k X K k X k Kk Kk k k k k k Kk k k k Kk k k k k k k k K k X k k k Kk k k k k k / 


{ 
Operator *op ptr; 
Line ZEND, 


g = fopen("graph.pic","w"); 
op ptr = op list->head; /* start at head of list */ 
while(op ptr != NULL) 
fprintf(g,"$dMn",op ptr-^optype); /* output each node */ 
fprintf(g,"$dWMn",op ptr-»xstart); 
fprint (C bol Nu OPNS tSt atl 
fprintf(g,"%d\n",op_ptr—>xstop) ; 
fprintf(g,"td\n",op ptr->ystop) ; 
fprintf(g,"$sWMn",op ptr-»name-»string):; 
fprintf(g,"%sin",op ptr->met->string); 


ln ptr = op ptr->head; /* scare aq head ot operator s */ 
/* line list */ 
while(ln ptr != NULL) 

{ /* output line node contents */ 
fprintf(g,"$dWMn",ln ptr-»lntype); 
fpruntf(g, "tdin" Ineptr-»xstart): 
fprintf(g, tain", in pter—systart); 

BODEM gusce nitatis EO) 
fpriBBf(g,"tdin",In ptr--ystop); 
fprintf(g,"%sin",ln ptr->name->string); 
fprintf(g,"is|in",In ptr-»dest-»string); 


Hp co Ir Cor next /* advance to next line */ 
} 
op_ptr = op_ptr->next; /* advance to next operator */ 
) 
fclose(g); 


) /* end store diagram */ 


las 


redraw_diagram() 
/ * & & & * k k K & K k K KK K k KUK k k KOK eie ks kk ko sk o a a a a AK KK RK KK A RIK A AX 


WRITTEN BY: R. K. Thorstenson 
LAST MODIFIED: 10 Nov 1988 


CALLS: draw object () 
display name() 
display met () 
draw arrowhead() 


CALLED BY: load proc() 
process canvas events () 


PURPOSE: This routine blanks out the screen and redraws each object 
stored in the operator list and each operator’s line list. 


* k k k k * k k k k k k k k k k k k K k k k k k k k k K K k k k k k k k k K K k K K k K k K kO k k Ok k k k k k k K k k k k k k K k K k K. 


{ 


Operator *op ptr; 
Line AP 


/* blank the screen */ 
pw writebackground (drawing pw,0,0, 
window get (drawing canvas,CANVAS WIDTH), 
window get (drawing canvas,CANVAS HEIGHT), 


PIX SRC); 
op ptr = op list->head; /* start at head of list */ 
while(op ptr !- NULL) 
( 
if(op ptr->optype == OPERATOR) 
( /* draw the object */ 


draw object (op ptr->optype,op ptr->xstart,op ptr->ystart, 
op ptr->xstop,op ptr->ystop); 
display name (op ptr->name,OPERATOR,op ptr->xstart, 
op ptr->ystart,op ptr->xstop,op ptr->ystop); 
display met (op ptr->met,op ptr->xstart,op ptr->ystart, 
op ptr-»xstop,op ptr-»ystop); 
) 


ln ptr = op ptr->head; /* start at head of line list */ 
while(ln ptr != NULL) 
{ /* draw the line */ 


draw object (ln ptr->Intype,ln ptr->xstart,ln ptr->ystart, 
nit r 60P np 230 E 
/* attach its arrowhead */ 
if (ln ptr->1lntype == SELF LOOP) 
draw arrowhead(ln ptr->xstop,ln ptr->ystop, 
ln ptr->xstop,ln ptr->ystart); 
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else 
draw arrowhead(ln ptr->xstart,ln ptr->ystart, 
ln ptr->xstop,ln ptr->ystop); 


display name(ln ptr->name,ln ptr->lntype,ln ptr->xstart, 
ln ptr->ystart,ln ptr->xstop,ln ptr->ystop); 


dpt I E next /* adv line pointer */ 
) 
op ptr = op ptr->next; /* advance the operator pointer */ 


) /* end redraw diagram */ 
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draw arrowhead(xl, yl, x2, y2) 
N K A OK K X K KOK KOK X X Kk ck Uk ck K K X k K K 2 K k X REX AER GR ER E E CD AE 


WRITTEN BY: R. K. Thorstenson 


LAST MODIFIED: 10 Nov 1988 


CALLS: N/A 


CALLED BY: process ane () 


redraw_diagram() 


PURPOSE: This routine draws an arrowhead at the end of a line at the 


appropriate angle. 


KK KK KK IK KK IK IK KI IK I kk koc ke ke coke kk ke ck Á ke OI II AI I IA ke k k k k k k k k k k k k k k k k K ke kk f 


int xl, yl, x2, y2} 


{ 


int xl trans, yl trans, x2 trans, y2 trans; 
int XPE Picea mec, me Vite aay 

xptl_trans, yptl trans, xpt2 trans, ypt2 trans; 
double length, 


theta; 
/* translate the line to the origin 
acd seins) SS ROL = seh 5 
yl an M A 27 


/* find the length of the line 
length - sqrt(pow((double)xl trans,2.0) + 
pow( (double) yl_trans,2.0)); 


/* find the angle between the line and the x axis 
theta - acos ((double)x1l trans/length); 


/* calculate the coords of the points of the arrowhead 
xpt1 = ARROW LENGTH * cos(theta + PI / 6.0); 
yptl = ARROW LENGTH * sin(theta + PI / 6.0); 


xpt2 = ARROW LENGTH * cos(theta PT ff 05 
ypt2 = ARROW_LENGTH * sin(theta - PI / 6.0); 


íx refiect y coords across x axis if yll trans is negative 
if (yl trans « 0) 
{ 
yptl = -yptl; 
ypt2 -ypt2; 


/* translate the arrowhead's coords out to the posit of the line 
xptl trans = xptl + x2; 
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yptl_trans = yptl + y2; 
xpt2 trans xpC2 + x2; 
ypt2_trans Viney 


/* draw the point of the arrow */ 
pw_vector (drawing pw, xptl trans, yptl trans, x2, y2, PIX SRC, 1); 
pw vector(drawing pw, xpt2 trans, ypt2 trans, x2, y2, PIX SRC, 1); 
pw vector(drawing pw, xptl trans, yptl trans, xpt2 trans, 
vpt2Ntrans PIXSSRC,I)E 


) /* end draw arrow head */ 
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